zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (06/20/89)
Test results from*:
/bin/time dd if=/dev/disk_block_device of=/dev/null bs=4k count=2000
Sys Opsys Drive Inter Systime KBytes/sec
Max IIx AUX1.0.1 Quantum SCSI 11.2 57
'386 Interactive Maxtor WD1006 17.4 400
5.3.2 MFM 1:1
'386 AT&T 3.2 CDC WD1007 9.4 319
25Mhz 94186 WA2 1:1
ESDI
3B2/ AT&T CDC MFM? 38.9 52
400
3B15 AT&T SMD 19.5 108
AT&T AT&T ESDI 14.1 52
'386
TI 1300 SCO 2.3.2 Mini WD1006 25 260
20Mhz Scribe RA2
6085 RLL?
TI 1300 SCO 2.3.2 CDC TI SCSI 12 349
20Mhz
'386 uPort 3.0e CDC Compaq
16Mhz ST-506 19.4 146
'386 SCO 2.3.0 MiniS Adaptec 24.3 190
3180E 2322
ESDI
'386 Inter MiniS Adaptec 13.8 522
25Mhz 2.0.2 9380E 2322
ESDI
'386 Inter Newbury Adaptec 8.1 677
25Mhz 2.0.2 9380E 1542A
SCSI
'386 uPort Maxtor Adaptec 10 182
16Mhz 3.0e 72MB 2372
RLL 1:1
Intel SCO CDC DPT
'386 2.3.1 3011/70
25Mhz 4.5MB 5.3 157
Tandy SCO Quantum Adaptec 10.5 85
16Mhz 2.2.4 Q-280 1540
'386 SCSI
Tandy uPort Seagate WD-1006 20.3 239
16Mhz 3.0e 4096 1:1
'386 MFM
16Mhz Inter Maxtor WD 17 190
'386 2.0.1 2:1
20Mhz Inter Hitachi Adaptec 12 416
'386 2.0.1 RLL 1:1
16Mhz SCO 2.3.1 Fujitsu Adaptec 11.2 372
'386 M2243as2 RLL 1:1
BULL SPIX 31.2 SCSI 18 226
16Mhz
68020
BULL uPort 3.0e Maxtor MFM 21 165
16Mhz 120MB
'386
SUN SUN OS Sync 5.1 516*
3/80 SCSI
SUN SUN OS " 4.2 550
Spark/1
SUN SUN OS " 2 521
4/110
DEC Ultrix SCSI 150
3100
* Note that some systems will cache the whole 8MB so you need to use a
32MB test and divide by 4 to get accurate results if you run the test more
than once.
I'm still interested in results for other systems.
--
Jon Zeeff zeeff@b-tech.ann-arbor.mi.us
Ann Arbor, MI sharkey!b-tech!zeeffzeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (06/22/89)
>Test results from*: > >/bin/time dd if=/dev/disk_block_device of=/dev/null bs=4k count=2000 > I should have made it clear that the Kbytes/sec results were based on realtime and hence I am only interested in results from unloaded systems. True, other data would be meaningless. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI sharkey!b-tech!zeeff
nvk@ddsw1.MCS.COM (Norman Kohn) (06/22/89)
In article <9468@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >Sys Opsys Drive Inter Systime KBytes/sec > >'386 Interactive Maxtor WD1006 17.4 400 >'386 AT&T 3.2 CDC WD1007 9.4 319 I have a problem here. Is systime supposed to be the time we're measuring? If so, these numbers can't be right (inconsistent kb/sec results). I must be missing something. -- Norman Kohn | ...ddsw1!nvk Chicago, Il. | days/ans svc: (312) 650-6840 | eves: (312) 373-0564
pb@idca.tds.PHILIPS.nl (Peter Brouwer) (06/22/89)
In article <9472@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >>Test results from*: >> >>/bin/time dd if=/dev/disk_block_device of=/dev/null bs=4k count=2000 >> > >I should have made it clear that the Kbytes/sec results were based on >realtime and hence I am only interested in results from unloaded systems. >True, other data would be meaningless. Why not use /dev/raw_disk_device as well to exclude the cache buffering in the system? -- # Peter Brouwer, ## # Philips TDS, Dept SSP-V2 ## voice +31 55 432523 # P.O. Box 245 ## UUCP address ..!mcvax!philapd!pb # 7300 AE Apeldoorn, The Netherlands ## Internet pb@idca.tds.philips.nl
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (06/23/89)
>>>Test results from*: >>> >>>/bin/time dd if=/dev/disk_block_device of=/dev/null bs=4k count=2000 >>> >Why not use /dev/raw_disk_device as well to exclude the cache buffering >in the system? > The intent is a very simple benchmark to measure something as close as possible to file system performance without introducing variables like fragmentation. Since normal disk i/o does go through the block device and the cache .... *unloaded systems using real times -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI sharkey!b-tech!zeeff
limes@sun.com (Greg Limes) (06/23/89)
In article <9468@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
Test results from*:
/bin/time dd if=/dev/disk_block_device of=/dev/null bs=4k count=2000
Sys Opsys Drive Inter Systime KBytes/sec
....
Sun SunOS Sync 5.1 516*
3/80 SCSI
Sun SunOS " 4.2 550
Spark/1
Sun SunOS " 2 521
4/110
DEC Ultrix SCSI 150
3100
Gee, any reason you put the Dec3100 down below the Sun stuff? I guess
that the async SCSI hits their performance pretty bad. Does it support
Sync SCSI at all? (I would not mind seeing performance info on this)
Anyway, here are a couple more numbers ... I unmounted a couple of
partitions that I have not yet loaded with data, and ran the test
on them. The system is running unmodified "SunOS 4.0.3 EXPORT" with
tuned file systems ("tunefs -a 32767 -d 0"); I quadrupled the transfer
size as recommended in the earlier article ... even so, we really
only get a little over one digit of precision.
Sun SunOS sd4c Sync 3.3 1300 (block)
SPARC/330 rsd4c SCSI 2.0 700 (char)
Sun SunOS xd0h SMD 2.9 1700 (block)
SPARC/370 rxd0h 2.0 900 (char)
Sun SunOS id001c IPI 2.7 1900 (block)
SPARC/390 rid001c 2.2 1200 (char)
(Minor Nits: its "Sun", not "SUN"; "SunOS", not "SUN OS"; and "SPARC",
not "Spark"; not that I particularly care, but the information may be
of interest. Makes you seem more authoratative when you get the names
right.)
-- Greg Limes [limes@sun]
A Happy Engineer with a SPARCstation 370 under his desk :-)
--
Greg Limes limes@sun.com ...!sun!limes 73327,2473 [chose one]hjespersen@trillium.waterloo.edu (Hans Jespersen) (06/24/89)
In article <LIMES.89Jun22162921@ouroborous.wseng.sun.com> limes@sun.com (Greg Limes) writes: >Gee, any reason you put the Dec3100 down below the Sun stuff? I guess >... >(Minor Nits: its "Sun", not "SUN"; "SunOS", not "SUN OS"; and "SPARC", >not "Spark"; not that I particularly care, but the information may be >of interest. Makes you seem more authoratative when you get the names >right.) Its DEC not Dec, DECstation 3100 or DECsystem 3100 not Dec3100; "not that I particularly care, but the information may be of interest. Makes you seem more authoratative when you get the names right." -- Hans Jespersen hjespersen@trillium.waterloo.edu uunet!watmath!trillium!hjespersen