🚀 go-pugleaf

>>> 					Amiga	Amiga	Mac-II	Sun
>>> 					Floppy	CLtd	A/UX	3/50
>>> 
>>> Read speed,    512 buffer (byte/sec) 11014	17133	55168	240499
>>> Read speed,   4096 buffer (byte/sec) 12024	17133	53708	234057
>>
>>Under the MacOS on a MacII configured with an 80 MB CMS Pro80ii (Quantum)
>>disk drive, I get a read speed of about 512 Kilobytes per second
>>using a buffer (not cache) size of 32 KB (see PBOpen in IM or setvbuffer()
>>under MPW C), while reading an unfragmented 8+ Megabyte file.  
>
>Let me see if I have this straight.  The mac II hardware (without DMA)
>is capable of reading data off the hard disk at 512Kb/sec, compared to
>the sun 3/50 (with DMA), which reads data at 240Kb/sec?

Just to add to the noise:

*** Generic Flame ON ***
There is a vast amount of overhead between your stopwatch and the bare
silicon.  I am sick to death of people whining about how if only the poor
Mac 512/+/SE/II only had DMA then how much faster the things would be.
I wager that far more difference in disk I/O time can be made by careful
tuning of the filesystem.  Proper cacheing makes all the difference in the
world.  The disk seek that isn't done is the fastest of all.  If you take
the time to analyze the amount of time spent in the various phases of the
SCSI disk transfer (as has been pointed out before by others) the seek time
of the disk usually dominates the data transfer time.  With SCSI, you can
really shovel the bytes quickly using the loop mode of the 68020 (cache)
and with proper care the interrupt-per-sector time can be minimized.  Since
the disk driver process has to intervene to find out where each disk block
is stored on the disk there is only a small advantage to having the DMA do
the transfer itself, unless the DMA is _extremely_ smart and can do it all
itself.  Many systems with VM can't DMA into pages that aren't locked down,
so this can add an extra transfer step.  

Since the Mac OS runs fastest with a 1/1 interleave on the hard disk it
is capable of keeping up at the full data rate of the disk.  For ST-506
bit densities this works out to 522 Kbytes/sec.  This is the maximum
possible rate, I would expect real numbers to be somewhat less.  (According
to the above posting it was 512 Kbytes/sec.  Not bad!)

I don't mean to froth, it's just that the raw hardware can be so
completely swamped by the software, and as a hardware designer I am
always being beat upon to speed things up.  Around here, software is
often 'harder' than hardware!  Time spent optimizing the software is
not often taken, especially when any fool can point to the system
diagram and say "Looky, no DMA, well I'se heard that you gotta have one to
go rilly fast...  put one in."  They rarely can look at the driver and
start talking about cache ageing algorithms needing a tune-up, or different
strategies for doing read-ahead and disk request sorting, or a different
directory structure to minimize lookup times!  Da*n, hardware is _so_
visible!

*** Generic Flame OFF ***

Not that DMA can't make a difference, but when I see a 10:1 discrepancy
between the raw hardware rate and the end application rate I don't look
at the raw hardware for the reason!

Flames to me, my office is cold today!

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC Systems Corp.
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!iscuva!jimc
! II      CCCCCC !  (509) 927-5757
+----------------+
			"With excitement like this, who is needing enemas?"