🚀 go-pugleaf

In article <8499@june.cs.washington.edu> rik@june.cs.washington.edu (Rik Littlefield) writes:
>In article <1213@ttds.UUCP>, jonasn@ttds.UUCP (Jonas Nygren) writes:
>< In article <8479@june.cs.washington.edu> rik@june.cs.washington.edu (Rik Littlefield -- that's me) writes:
>< < In article <185@dg.dg.com>, rec@dg.dg.com (Robert Cousins) writes:
>< < < Given that a disk channel will be averaging 200K bytes/second ...
>< < ...
>< < Would someone with real utilization numbers care to fill us in?
>< 
>< I have performed a small test on a DECstation3100 with a RZ55-230 Mb disk.
>< The test used 15 processes reading/writing 2Mb files each, with the following
>< results:
><  <stuff deleted> 
>< Mean value: 234 kb/s
>
>Sure, but how much of the time does your workstation run 15 processes reading
>and writing the disk as fast as it can?  Program loads and file copies run at
>200 Kb/sec, program builds do maybe 10X less I/O, SPICE just crunches.
> ...

Er uhm.. excuse me.. but I think there may be two issues here.  One is quantity
of I/O, and the other is rate of I/O.  This experiment with 15 processes doing
lots of I/O probably (IMHO) comes close to determining the rate of transfer
which is maintained when the system is actually reading from disk.  Thus, for
brief intervals, the system is doing transfers at the rate of 234kb/s, and it
is this rate which the CPU/DMA_device must keep up with, IN ADDITION to keeping
up with all other events/interrupts at the same time.  Sure, so it's only busy
for a second once every 30 seconds, but it still ought to be able to handle the
load when it comes.  Now imagine a system with several users running BIG 
simulations, with the associated paging going on as their tasks (and the 30
or so daemons which are always running) get swapped.  Personally, I'd like the
I/O to be fast, and I'd also like not to have to type slowly as I am doing
right now (about a two second pause between hitting a key and seeing the result
at times).  DMA might be appropriate for such a system.  Especially since the
CPU could easily be running something else from its huge caches, leaving lots
of idle bus cycles for the DMA.  This does not require dual port memory, but 
does require some sort of snooping (h/w or s/w) to maintain cache consistancy.

As processors continue to become much faster than the memory bus, DMA seems to
begin looking better and better for bulk data transfers with slower I/O devices.

-Mark