Path: utzoo!mnetor!uunet!iscuva!jimc From: jimc@iscuva.ISCS.COM (Jim Cathey) Newsgroups: comp.sys.mac Subject: Re: A/UX disk I/O (real numbers) Message-ID: <1203@iscuva.ISCS.COM> Date: 29 Feb 88 19:08:38 GMT References: <8802251936.AA23485@cory.Berkeley.EDU> <7215@agate.BERKELEY.EDU> <5314@spool.cs.wisc.edu> Organization: ISC Systems Corporation, Spokane, WA Lines: 69 >>> 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?"