🚀 go-pugleaf

In article <C1E0sw.I4o@unix.portal.com> danb@shell.portal.com (Dan E Babcock) writes:
>In article <1993Jan24.014406.27423@mlb.semi.harris.com> sonny@trantor.
harris-atd.com (Bob Davis) writes:>>In article <1993Jan23.231824.24755@rose.
com> gyl.midroni@rose.com (gyl midroni) writes:

>>       Even the fastest single drives can only spin the bytes under
>>the drive's head at around 3 million bytes/sec.

>That's about right. A few can break 4MB/s.

Can you say "on-board cache"?

>>       So, isn't a 5.33 million bytes/sec 16-bit slot on the ISA bus pretty
>>much up to the task of delivering and retrieving data to and from a
>>single hard drive that is only capable of spinning the data off or onto
>>the platters at a 3 million bytes/sec rate?

There's no such animal on an AT.  5.33 MB/sec would require absolutely no 
interruptions and no wait-states on an IO cycle at 8 MHz.

This rarely happens, especially if you are copying a file, for example.  The 
file must go in and out over the same bus.  As you say, if it goes back to 
the same drive, then the drive could be a limitation, also, but if you are 
pumping it out over a network or to your screen or something else, the drive 
is not getting full bus utility anyway.

>>       And isn't it expensive overkill to provide a 132 million bytes/sec
>>truck (local bus) to haul 3 million bytes/sec freight ( a fast hard drive's
>>maximum, spin-limited data transfer rate)?  Seems like that expensive local 

Yes, no.  You hardly ever get to use 100% of what is there.  33 * 4 MBytes/
sec may indeed be overkill, but it will definitely give you more throughput 
even on a single drive, especially if there is any cache involved.  The 
cache will transfer at the full speed of the bus, plus any wait states.

>The "132MB/s" figure is just for marketing. The actual transfer rate is
>limited by the speed of DRAMs. 20-30MB/s is realistic.

This depends.  If you have near 0 wait-state operation, you can pump this 
stuff off the bus back into RAM at 4 bytes / clock cycle on a 486.

But again, your bus may have wait states, and if memory is not interleaved 
and fast, you won't really get close to 0 ws operation.  If you figure 1 bus 
ws and 2 mem ws, then you can transfer 4 bytes from bus to mem in 5 cycles.  
This is indeed within the quoted range.

But remember the AT bus is subject to all that limitation also.

>You hit the nail on the head: all this only matters if you're using an
>OS that will take advantage of it (i.e. not MSDOS :-))

This doesn't figure with my experience.  Improvement under DOS is not as 
dramatic as you would conclude from the figures, but it is significant.

>>system without heavy multitasking requirements. Certainly, I am not going
>>to improve the prolonged data transfer rate onto or off the disk -- 
>>3 million bytes/sec is as fast as data physically can be sucked up or spewed
>>out.

>Right. It goes without saying that a faster bus is not going to improve
>single-drive performance.

Not true.  Bus delay is ON TOP of the disk access speed.  You will in any 
case increase total throughput because the data spends less time on the bus, 
all other things being equal.

Not only that, I have seen it :-D
 -----------Visit the SOUNDING BOARD BBS 214-596-2915, a Wildcat! BBS--------
 ObQuotes:
 "Quick to judge, quick to anger, slow to understand..."
 "Ignorance and prejudice, and fear go hand-in-hand..."

    Patrick Taylor, Ericsson Network Systems
    exuptr@exu.ericsson.se                    "Don't let the .se fool you"