Path: utzoo!utgpu!watmath!isishq!f171.n221.z1.FIDONET.ORG!izot
From: izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh)
Newsgroups: comp.sys.cbm
Subject: Re: SEQ file access speedup
Message-ID: <1607.23F8D160@isishq.FIDONET.ORG>
Date: 14 Feb 89 21:14:13 GMT
Sender: ufgate@isishq.FIDONET.ORG (newsout1.25)
Organization: FidoNet node 1:221/171 - Izot's Swamp, Kitchener ON
Lines: 59


 > From: elg@killer.DALLAS.TX.US (Eric Green)
 > Message-ID: <7143@killer.DALLAS.TX.US>
 
Eric:
 
   Your benchmarks are interesting and informative, but I'd like to point out
something you said which is mildly misleading:
 
 > Some trivia: the main difference between LOAD'ing (burst mode) and
 > READ'ing (fastmode) on the 1571 is that fast mode negotiates a
 > transaction for each byte, while burst mode negotiates on a per-block
 > basis. Burst mode is unique in that manner -- even the IEEE drives
 > negotiate on a per-byte basis (probably why they're slower than burst
 > mode, despite fairly equivalent hardware).
 
   On true (parallel) IEEE drives, there is nothing to negotiate. While burst 
mode transactions on a 1571 or 1581 do have to be set up in slow (i.e. 1541 
speed) mode, there is no need for such arrangements on the parallel drive... 
in fact, the parallel drives have lower overheads because the handshake 
suffices for inter-byte holdoffs.
 
   Furthermore, the IEEE drives do NOT have "fairly equivalent hardware"... 
burst mode handshaking is done in hardware (at a rate dependent on gate 
timings, but the gates operate at less than 50 nanoseconds each), while IEEE 
handshaking is done in software at a rate dependent on instructions taking two 
to six clock cycles taking 1,000 nanoseconds per.
 
   Given hardware handshaking and DMA, some IEEE-488 bus instruments achieve 
data transfer rates in the hundresd of thousands of bytes per second.
 
 > Some other trivia: Using ACPTR should be faster than using GETIN, if
 > subroutine overhead is as big a problem as some hint. GETIN has to
 > do all sorts of testing to see where to dispatch to -- is it keyboard,
 > or is it disk? This overhead should be noticible when compared to
 > LOAD, which calls ACPTR directly. But for both the IEEE drives and the
 > 1541, there was no significant difference between LOAD and GETIN
 > times, implying that transfer speed, and not internal Kernal overhead,
 > was the limitation.
 
   The subroutine overhead, as they say, is a drop in the bucket. Using GETIN 
will be slower than using ACPTR, but only marginally.
 
===========================================================================
Internet:  Geoffrey.Welsh@f171.n221.z1.fidonet.org | 66 Mooregate Crescent
Usenet:    watmath!isishq!izot                     | Suite 602
FidoNet:   Geoffrey Welsh on 1:221/171             | Kitchener, Ontario
PunterNet: 7/Geoffrey Welsh                        | N2M 5E6 CANADA
BBS:       (519) 742-8939 24h 7d 300/1200/2400bps  | (519) 741-9553
===========================================================================
|  "I don't need a disclaimer. No one pays any attention to what I say."  |
===========================================================================
 


--  
 Geoffrey Welsh - via FidoNet node 1:221/162
     UUCP: ...!watmath!isishq!171!izot
 Internet: izot@f171.n221.z1.FIDONET.ORG