mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (05/01/87)
In the process of buying a hard disk, I dug out the disk performance tester on Fish disk 48, and ran it on the disks I could get my hands on. I also added some other odds and ends, like the 33.47 ram: driver (why does it write noticably slower than the 33.46 one? Slow ram expansion?), the katin vdk:, and the fastest disk system I could get my code on (well, second fastest. I may have more numbers later, as we are probably going to investigate the new VAX I/O architechtures. Let me know if you're interested). The Xebec drive appears to do file creations/deleteions noticably slower than anything else; I suspect that that is due to it using a larger buffer (1K vs. 512), but I don't have proof that it's doing that. Someone like to comment on this? Likewise, the slow speed of VAX writes on small buffers is attributable to using an 8k/1k file system, meaning you copy the data up to twice on 4096 byte buffers, and up to 8 times on the 512 byte buffers. I don't know what the block/frag size for the Sun was. Those who doubt that AmigaDOS does good things for finding files vs. the Unix file system might check out the file creations/deletions #'s vs. raw throughput. Now, if someone could explain why scanning a directory is so mach faster relative to the raw disk speed on AmigaDOS, I'd appreciate it. Numbers of opens/sec would be interesting. I may hack the diskperf program to do that. Finally, based on these numbers, I bought the Xebec drive. I'll have more to say about that early next week. <mike disk file creations file deletions directory scan seek and read system per second per second entries/second per second df1: <=1 1 38 2 vdk: (katin) 7 90 78 * vd0: (asdg) 18 43 51 132 ram: (33.46) 5 10 5 51 ram: (33.47) 5 10 5 51 CLtd 7 15 50 40 Microbotics 4 8 45 34 Xebec 2 3 45 49 Sun 3/50 6 11 350 298 VAX 8800 (kdb) 13 29 1629 1914 Disk throughput in bytes/second disk -- read with buffer sizes: -- -- write with buffer sizes: - system 512 4096 8192 32768 512 4096 8192 32768 df1: 11014 12024 12080 12136 4974 5180 5170 5190 vdk: (katin) 218453 655360 655360 873813 79437 113975 113975 119156 vd0: (asdg) 70849 109226 113975 119156 46811 63937 65536 67216 ram: (33.46) 201649 655360 873813 873813 137970 262144 291271 327680 ram: (33.47) 201649 655360 873813 873813 131072 238312 262144 262144 Cltd 17133 17133 17133 17133 12603 13512 13653 13797 Microbotics 14169 15984 16282 16384 9463 9602 9676 9745 Xebec 32363 37991 37991 37991 12663 13239 13512 13639 Sun 3/50 240499 234057 233189 236343 215166 182466 179755 187580 VAX 8800 (kdb) 449389 421679 419990 410669 146585 183960 185807 191812 Notes: (1) vd0: & Cltd done under 1.2 release 33.46. (2) Microbotics, Xebec and vdk: done under 1.2 release 33.47 (3) ram: don on 1.2, with the release in parens for comparison. (4) df1: tests done after "addbuffers 32" & fresh formatted disk (5) vd0: tests done with 2Mb recoverable ram disk, nearly full. (6) ram: tests done with ASDG ram attached and active for ram: use (7) All 33.46 Amiga timings done by Fred Fish. Sun-30/50 timings by Rick Spanbauer. (8) 33.47 Amiga and VAX 8800 timings done by Mike Meyer. (9) The Sun timing shows you what a high-perforamance system talking to a SCSI can do. The VAX timing shows what a high-performance I/O system can do. (*) The vdk: driver would couldn't create the file for this test. -- Take a magic carpet to the olden days Mike Meyer To a mythical land where everybody lays ucbvax!mwm Around in the clouds in a happy daze mwm@berkeley.edu In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNET
cmcmanis@sun.uucp (Chuck McManis) (05/04/87)
In article <3406@jade.BERKELEY.EDU>, (Mike (My watch has windows) Meyer) writes: > Those who doubt that AmigaDOS does good things for finding files vs. > the Unix file system might check out the file creations/deletions #'s > vs. raw throughput. Now, if someone could explain why scanning a > directory is so mach faster relative to the raw disk speed on > AmigaDOS, I'd appreciate it. Numbers of opens/sec would be > interesting. I may hack the diskperf program to do that. I think you will find that ADOS is incredibly fast at opening *named* files. Because of the hashing scheme and the fairly large hash tables (76 entries in 512 byte blocks). Consequently opening a file usually takes only 2 reads in most cases (the directory block and the file header) with digressions to 3 and sometimes 4 reads when the directory is *really* loaded. DiskPerf's code for checking the 'scan' rate looks like : /* ** Time open scan of directory. */ timer(0); numRead = 1; for(i = 0; i < SCAN_ITER; i++) for(j = 0; j < OPEN_TEST_FILES; j++) if(OpenStat(tempname[i]) != 0) numRead++; timer(&sDt); Where OpenStat just gets a Lock on a filename and does an Examine on that lock. This wins because of the hashing. There is very little scanning, and a lot of jump right to the file you want. Unfortunately optimizing for speed of the 'Dir' command actually hurts lookup time. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These views are my own and no one elses. They could be yours too, just call MrgCop() and then ReThinkonrge Robbr
bnrrtp@mcnc.UUCP (05/07/87)
Newsgroups: comp.sys.amiga Subject: Re: Disk timings.... Summary: Expires: References: <3406@jade.BERKELEY.EDU> Sender: Jay Denebeim Reply-To: bnrrtp@speedy.UUCP (Jay Denebeim) Followup-To: Distribution: Organization: Side Effects, Inc. Keywords: I thought some of you folks might be interested in the numbers we get for the Side ARM. In article <3406@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: disk file creations file deletions directory scan seek and read system per second per second entries/second per second df1: <=1 1 38 2 vdk: (katin) 7 90 78 * vd0: (asdg) 18 43 51 132 ram: (33.46) 5 10 5 51 ram: (33.47) 5 10 5 51 CLtd 7 15 50 40 Side Track 8 13 51 50 Microbotics 4 8 45 34 Xebec 2 3 45 49 Sun 3/50 6 11 350 298 VAX 8800 (kdb) 13 29 1629 1914 Disk throughput in bytes/second disk -- read with buffer sizes: -- -- write with buffer sizes: - system 512 4096 8192 32768 512 4096 8192 32768 df1: 11014 12024 12080 12136 4974 5180 5170 5190 vdk: (katin) 218453 655360 655360 873813 79437 113975 113975 119156 vd0: (asdg) 70849 109226 113975 119156 46811 63937 65536 67216 ram: (33.46) 201649 655360 873813 873813 137970 262144 291271 327680 ram: (33.47) 201649 655360 873813 873813 131072 238312 262144 262144 Cltd 17133 17133 17133 17133 12603 13512 13653 13797 Microbotics 14169 15984 16282 16384 9463 9602 9676 9745 Side Track 25954 25450 25206 25700 14324 19275 19134 20641 Xebec 32363 37991 37991 37991 12663 13239 13512 13639 Sun 3/50 240499 234057 233189 236343 215166 182466 179755 187580 VAX 8800 (kdb) 449389 421679 419990 410669 146585 183960 185807 191812 >Notes: > (1) vd0: & Cltd done under 1.2 release 33.46. > (2) Microbotics, Xebec and vdk: done under 1.2 release 33.47 > (3) ram: don on 1.2, with the release in parens for comparison. > (4) df1: tests done after "addbuffers 32" & fresh formatted disk > (5) vd0: tests done with 2Mb recoverable ram disk, nearly full. > (6) ram: tests done with ASDG ram attached and active for ram: use > (7) All 33.46 Amiga timings done by Fred Fish. Sun-30/50 timings > by Rick Spanbauer. > (8) 33.47 Amiga and VAX 8800 timings done by Mike Meyer. > (9) The Sun timing shows you what a high-perforamance system > talking to a SCSI can do. The VAX timing shows what a > high-performance I/O system can do. > (*) The vdk: driver would couldn't create the file for this test. >-- >Take a magic carpet to the olden days Mike Meyer As a side note, this program isn't typical of the sorts of things most of us do on our Amigas. However, this seems to be about the only benchmark for hard disks on the Amiga currently. Jay Denebeim UUCP: bnrrtp@mcnc.uucp Data: 919-471-6436 Newsgroups: comp.sys.amiga Subject: Re: Disk timings.... Summary: Expires: References: <3406@jade.BERKELEY.EDU> Sender: Reply-To: bnrrtp@speedy.UUCP (Stanley T. Chow) Followup-To: Distribution: Organization: Microelectronics Center of NC; RTP, NC Keywords: Newsgroups: comp.sys.amiga Subject: Re: Disk timings.... Summary: Expires: References: <3406@jade.BERKELEY.EDU> Sender: Jay Denebeim Reply-To: bnrrtp@speedy.UUCP (Jay Denebeim) Followup-To: Distribution: Organization: Side Effects, Inc. Keywords: I thought some of you folks might be interested in the numbers we get for the Side ARM. In article <3406@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: > >disk file creations file deletions directory scan seek and read >system per second per second entries/second per second > >df1: <=1 1 38 2 > >vdk: (katin) 7 90 78 * >vd0: (asdg) 18 43 51 132 >ram: (33.46) 5 10 5 51 >ram: (33.47) 5 10 5 51 > >CLtd 7 15 50 40 Side Track 8 13 51 50 >Microbotics 4 8 45 34 >Xebec 2 3 45 49 > >Sun 3/50 6 11 350 298 >VAX 8800 (kdb) 13 29 1629 1914 > > Disk throughput in bytes/second >disk -- read with buffer sizes: -- -- write with buffer sizes: - >system 512 4096 8192 32768 512 4096 8192 32768 > >df1: 11014 12024 12080 12136 4974 5180 5170 5190 > >vdk: (katin) 218453 655360 655360 873813 79437 113975 113975 119156 >vd0: (asdg) 70849 109226 113975 119156 46811 63937 65536 67216 >ram: (33.46) 201649 655360 873813 873813 137970 262144 291271 327680 >ram: (33.47) 201649 655360 873813 873813 131072 238312 262144 262144 > >Cltd 17133 17133 17133 17133 12603 13512 13653 13797 >Microbotics 14169 15984 16282 16384 9463 9602 9676 9745 Side Track 25954 25450 25206 25700 14324 19275 19134 20641 >Xebec 32363 37991 37991 37991 12663 13239 13512 13639 > >Sun 3/50 240499 234057 233189 236343 215166 182466 179755 187580 >VAX 8800 (kdb) 449389 421679 419990 410669 146585 183960 185807 191812 > >Notes: > (1) vd0: & Cltd done under 1.2 release 33.46. > (2) Microbotics, Xebec and vdk: done under 1.2 release 33.47 > (3) ram: don on 1.2, with the release in parens for comparison. > (4) df1: tests done after "addbuffers 32" & fresh formatted disk > (5) vd0: tests done with 2Mb recoverable ram disk, nearly full. > (6) ram: tests done with ASDG ram attached and active for ram: use > (7) All 33.46 Amiga timings done by Fred Fish. Sun-30/50 timings > by Rick Spanbauer. > (8) 33.47 Amiga and VAX 8800 timings done by Mike Meyer. > (9) The Sun timing shows you what a high-perforamance system > talking to a SCSI can do. The VAX timing shows what a > high-performance I/O system can do. > (*) The vdk: driver would couldn't create the file for this test. >-- >Take a magic carpet to the olden days Mike Meyer As a side note, this program isn't typical of the sorts of things most of us do on our Amigas. However, this seems to be about the only benchmark for hard disks on the Amiga currently. Jay Denebeim UUCP: bnrrtp@mcnc.uucp Data: 919-471-6436
rokicki@rocky.UUCP (05/07/87)
> Cltd 17133 17133 17133 17133 12603 13512 13653 13797 Cltd 24272 24499 24499 24499 12787 18204 18859 19275 > Microbotics 14169 15984 16282 16384 9463 9602 9676 9745 > Side Track 25954 25450 25206 25700 14324 19275 19134 20641 > Xebec 32363 37991 37991 37991 12663 13239 13512 13639 Not *too* big of a difference, but Cltd doesn't look *quite* so bad. Other values were close. Cltd has promised a new, faster driver with (I hear) up to 50% faster throughput . . . -tom