fnf@fishpond.UUCP (Fred Fish) (02/23/88)
In article <1693@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >But what alot of wishful thinking A/UX users are forgetting is that the >3/60 also can act as a server (remember the thing will proabably also have >much faster disk I/O thanks to the DMA). The person I'm working with >bought a diskless 3/50 and can use the 3/60 disk. Cheap and relatively >fast compared to what an A/UX Mac II can or can't do. Of course the whole >idea of a fast server for many Mac II's hung off of it, is something yet >to be addressed by Apple. Second, the diskless Sun will soon be able to >boot off of non-Sun equipment! Ok, with all the speculation about disk I/O, and the advantages/disadvantages of DMA, I decided to drag out and dust of a disk performance benchmark written by Rick Spanbauer a LONG time ago and used to test Amiga hard disks when they first became available. Since I already had Sun 3/50 timings, all I had to do were the A/UX ones. Here are my measured results using the diskperf.c program, and ballpark verified using the Unix dd program: Performance timings using Rick Spanbauer's diskperf.c program. Amiga Amiga Mac-II Sun Floppy CLtd A/UX 3/50 df1: dh0: HD80SC File creations (files/sec) <=1 7 6 6 File deletions (files/sec) 1 15 8 11 Directory scan (entries/sec) 38 50 371 350 Seek+read (seek+read/sec) 2 40 110 298 Read speed, 512 buffer (byte/sec) 11014 17133 55168 240499 Read speed, 4096 buffer (byte/sec) 12024 17133 53708 234057 Read speed, 8192 buffer (byte/sec) 12080 17133 54013 233189 Read speed, 32768 buffer (byte/sec) 12136 17133 53644 236343 Write speed, 512 buffer (byte/sec) 4974 12603 44181 215166 Write speed, 4096 buffer (byte/sec) 5180 13512 47211 182466 Write speed, 8192 buffer (byte/sec) 5170 13653 46832 179755 Write speed, 32768 buffer (byte/sec) 5190 13797 46930 187580 Notes: (1) All Amiga tests done under 1.2 release 33.46. (2) df1: tests done after "addbuffers 32" & fresh formatted disk (3) All Amiga and Mac-II timings done by Fred Fish. (4) Sun-30/50 timings by Rick Spanbauer. -- # Fred Fish hao!noao!mcdsun!fishpond!fnf (602) 921-1113 # Ye Olde Fishpond, 1346 West 10th Place, Tempe, AZ 85281 USA
jaw@eos.UUCP (James A. Woods) (02/24/88)
From article <6@fishpond.UUCP>, by fnf@fishpond.UUCP (Fred Fish): > > Amiga Amiga Mac-II Sun > Floppy CLtd A/UX 3/50 > df1: dh0: HD80SC > > Read speed, 512 buffer (byte/sec) 11014 17133 55168 240499 > Read speed, 4096 buffer (byte/sec) 12024 17133 53708 234057 for the mac2, these numbers harden the very rough timing for time cat /usr/dict/words > /dev/null (~200K bytes in four CPU seconds) done on an beta a/ux a year ago. it looks almost entirely due to the speed of the system5 vs. bsd4.2 filesystem. considering how much other bsd stuff apple picked up, why they didn't go for the berkeley filesystem is beyond me ...
martin@uhccux.UUCP (Brian Martin) (02/25/88)
In article <219@eos.UUCP> jaw@eos.UUCP (James A. Woods) writes: >From article <6@fishpond.UUCP>, by fnf@fishpond.UUCP (Fred Fish): >> >> Amiga Amiga Mac-II Sun >> Floppy CLtd A/UX 3/50 >> df1: dh0: HD80SC >> >> Read speed, 512 buffer (byte/sec) 11014 17133 55168 240499 >> Read speed, 4096 buffer (byte/sec) 12024 17133 53708 234057 > >for the mac2, these numbers harden the very rough timing for > > time cat /usr/dict/words > /dev/null > >(~200K bytes in four CPU seconds) done on an beta a/ux a year ago. it >looks almost entirely due to the speed of the system5 vs. bsd4.2 filesystem. >considering how much other bsd stuff apple picked up, >why they didn't go for the berkeley filesystem is beyond me ... Actually, they did go for the Berkeley file system. I was at an A/UX demo last week, and managed to corner their engineer. It turns out that they are using an antiquated version of the Berkeley file system, back before symbolic pointers were introduced. Some other interesting points... Although Apple bundles in the Documenter's Work Bench, their troff doesn't produce Postscript output. You still need to buy one of the 3rd-party troff packages that supports Postscript. The "site license" for A/UX is $25,000. But they didn't know how a site license would be handled, e.g., whether one Apple-supplied disk would be sold to the user, from which multiple copies of A/UX would be loaded onto other disks. Security might be a problem. It seems that you could boot the Mac OS, then use a Mac program to scan and modify i-node information on the A/UX disk, effectively bypassing the /etc/passwd and /etc/group protections. The Apple engineer didn't have a good answer to this potential problem; perhaps someone else does. Regards, Brian K. Martin, M.D. ARPA: uhccux!medix!martin@nosc.MIL UUCP: { ihnp4,ucbvax,dcdwest,uunet }!ucsd!nosc!uhccux!medix!martin
dillon@CORY.BERKELEY.EDU (Matt Dillon) (02/26/88)
:In article <219@eos.UUCP> jaw@eos.UUCP (James A. Woods) writes:
:>From article <6@fishpond.UUCP>, by fnf@fishpond.UUCP (Fred Fish):
:>>
:>> Amiga Amiga Mac-II Sun
:>> Floppy CLtd A/UX 3/50
:>> df1: dh0: HD80SC
:>>
:>> Read speed, 512 buffer (byte/sec) 11014 17133 55168 240499
:>> Read speed, 4096 buffer (byte/sec) 12024 17133 53708 234057
:>
The new Fast File System for the Amiga will go at 75KBytes/sec.
(600Kbps). Also, the CLtd HD is the worst possible choice one can make
for a comparison.
-Mattwetter@tybalt.caltech.edu (Pierce T. Wetter) (02/26/88)
> >Security might be a problem. It seems that you could boot the Mac OS, >then use a Mac program to scan and modify i-node information on the >A/UX disk, effectively bypassing the /etc/passwd and /etc/group >protections. The Apple engineer didn't have a good answer to this >potential problem; perhaps someone else does. > On any unix system this is a problem. Go up to a micro version of unix. Reboot from a floppy with a small unix kernel on it. (say XENIX and the XENIX distribution disk). you will now be superuser. Edit the /etc/passwd file so that root has no password. Reboot. Anytime anyone has full access to a system you don't have security. That's why god created machine rooms. Note that the above instructions were taken from the Microsoft XENIX manual What to do if you Forget the SuperUser Password. Bozos. Pierce Wetter Today's scientific question is: What in the world is electricity? And where does it go after it leaves the toaster? -- Dave Barry, "What is Electricity?" -------------------------------------------- wetter@tybalt.caltech.edu --------------------------------------------
fnf@fishpond.UUCP (Fred Fish) (02/26/88)
In article <8802251936.AA23485@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > [references to an A/UX IO message I posted... -fnf] > The new Fast File System for the Amiga will go at 75KBytes/sec. >(600Kbps). Also, the CLtd HD is the worst possible choice one can make >for a comparison. I neglected to point out to the comp.sys.mac readers, who probably aren't at all familiar with the history of Amiga hard disks, that the numbers I posted were VERY old, from one of the first hard disks available. I agree 100% that these numbers should not be used to make comparisons between the two machines. The Amiga situation has improved considerably! Sorry about any confusion... -Fred -- # Fred Fish hao!noao!mcdsun!fishpond!fnf (602) 921-1113 # Ye Olde Fishpond, 1346 West 10th Place, Tempe, AZ 85281 USA
cswarren@gershwin.berkeley.edu (Warren Gish;133B Biochem;x3-9219) (02/27/88)
> Amiga Amiga Mac-II Sun > Floppy CLtd A/UX 3/50 > df1: dh0: HD80SC > > 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. With a buffer smaller than about 31 KB, the read speed drops dramatically to about 32 KB/sec. Warren Gish IST UC Berkeley cswarren@violet.berkeley.edu
planting@speedy.cs.wisc.edu (W. Harry Plantinga) (02/29/88)
>> 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? Wow!
jimc@iscuva.ISCS.COM (Jim Cathey) (03/01/88)
>>> 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?"
andy@cbmvax.UUCP (Andy Finkel) (03/01/88)
In article <8802251936.AA23485@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >:In article <219@eos.UUCP> jaw@eos.UUCP (James A. Woods) writes: >:>From article <6@fishpond.UUCP>, by fnf@fishpond.UUCP (Fred Fish): >:>> >:>> Amiga Amiga Mac-II Sun >:>> Floppy CLtd A/UX 3/50 >:>> df1: dh0: HD80SC >:>> >:>> Read speed, 512 buffer (byte/sec) 11014 17133 55168 240499 >:>> Read speed, 4096 buffer (byte/sec) 12024 17133 53708 234057 >:> > > The new Fast File System for the Amiga will go at 75KBytes/sec. >(600Kbps). Also, the CLtd HD is the worst possible choice one can make >for a comparison. Actually, with the 2090 Hard disk controller, and a nice fast SCSI drive like the Conners we get over 600KBytes/sec read speeds. -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Never test for an error condition you don't know how to handle." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
howard@cpocd2.UUCP (Howard A. Landman) (03/02/88)
In article <5314@spool.cs.wisc.edu> planting@speedy.cs.wisc.edu (W. Harry Plantinga) writes: >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? This is apples and oranges (Apples and Sun-sets?) because the 512KB/s was "best case", i.e. "an unfragmented 8+ Megabyte file", while the Sun number is "typical", i.e. a benchmark designed to be representative of the typical state of a real system. Also the Mac was running Mac OS, not UNIX, and the file might have been in the top-level of the disk, thus avoiding any HFS overhead. Without more info the number is intriguing but inconclusive. Also, buffer size *can* have an immense impact on performance, but it always has an effect on memory usage as well. Imagine 20 files open with a 32KB buffer for each - that's 640KB just for file buffers. Not a big problem in an 8 MB machine, but on a 1MB or 2MB machine? -- Howard A. Landman {oliveb,hplabs}!intelca!mipos3!cpocd2!howard howard%cpocd2.intel.com@RELAY.CS.NET