Date: Fri, 8 Aug 1997 11:12:45 -0500 From: Bob Willcox <bob@pmr.com> To: "John S. Dyson" <toor@dyson.iquest.net> Cc: Atipa <freebsd@atipa.com>, dyson@FreeBSD.ORG, ggm@connect.com.au, current@FreeBSD.ORG Subject: Re: IDE vs SCSI was: flags 80ff works (like anybody doubted it) Message-ID: <19970808111245.30561@pmr.com> In-Reply-To: <199708080427.XAA02012@dyson.iquest.net>; from John S. Dyson on Thu, Aug 07, 1997 at 11:27:18PM -0500 References: <Pine.BSF.3.91.970807215005.4224A-100000@dot.ishiboo.com> <199708080427.XAA02012@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I get some rather curious results with the program that John posted
in his email (the one to time command overhead, etc.). I have 8 SCSI
drives (sorry, I'm IDE phobic :-) on my workstation here with two NCR
(Symbios) based SCSI controllers (one 810, the other 875) that give me
the following results when running said program on them. Note that the
dd command run was:
dd bs=64k count=1600 if=/dev/rsd0 of=/dev/null
on each drive.
sd0 (SEAGATE ST12550N 0014 on 810 controller):
Program results:
Command overhead is 1005 usec (time_4096 = 2181, time_8192 = 3358)
transfer speed is 3.48128e+06 bytes/sec
dd results:
104857600 bytes transferred in 19.621211 secs (5344094 bytes/sec)
sd1 (SEAGATE ST32430N 0510 on 810 controller):
Program results:
Command overhead is -8610 usec (time_4096 = 1312, time_8192 = 11236)
transfer speed is 412762 bytes/sec
dd results:
104857600 bytes transferred in 18.049659 secs (5809395 bytes/sec)
sd2 (SEAGATE ST32430N 0510 on 810 controller):
Program results:
Command overhead is -8481 usec (time_4096 = 1313, time_8192 = 11108)
transfer speed is 418154 bytes/sec
dd results:
104857600 bytes transferred in 18.125932 secs (5784949 bytes/sec)
sd3 (FUJITSU M1606S-512 6218 on 810 controller):
Program results:
Command overhead is 11101 usec (time_4096 = 11106, time_8192 = 11111)
transfer speed is 7.94723e+08 bytes/sec
dd results:
104857600 bytes transferred in 23.335624 secs (4493456 bytes/sec)
sd4 (FUJITSU M1606S-512 6218 on 810 controller):
Program results:
Command overhead is 11081 usec (time_4096 = 11110, time_8192 = 11140)
transfer speed is 1.37759e+08 bytes/sec
dd results:
104857600 bytes transferred in 23.325748 secs (4495359 bytes/sec)
sd5 (Quantum XP32150 81HB on 875 controller):
Program results:
Command overhead is 436 usec (time_4096 = 928, time_8192 = 1420)
transfer speed is 8.32365e+06 bytes/sec
dd results:
104857600 bytes transferred in 15.045864 secs (6969198 bytes/sec)
sd6 (CONNER CFP4207W 4.28GB 1524 on 875 controller):
Program results:
Command overhead is 8383 usec (time_4096 = 8424, time_8192 = 8465)
transfer speed is 1.00552e+08 bytes/sec
dd results:
104857600 bytes transferred in 15.943513 secs (6576819 bytes/sec)
sd7 (Quantum XP32150 576D on 875 controller):
Program results:
Command overhead is 540 usec (time_4096 = 965, time_8192 = 1390)
transfer speed is 9.64218e+06 bytes/sec
dd results:
104857600 bytes transferred in 15.646630 secs (6701609 bytes/sec)
The first thing I noticed was that the command overhead times were
significantly & consistently higher with certain disks. But what really
through me was that some of them are negative! Take a look at sd1 & sd2.
The 8k read times are almost an order of magnitude greater than the
4k times. Is it possible I'm seeing the results of some bazaar cache
behavior in these disks (there 2gb Seagate Hawks)?
Also, I noticed that for the disks with the outrageously high command
overhead times (sd3, sd4, & sd6) that the dd times are in the range of
what I expected. Also, when I modified the program to read sequential
blocks, rather than offset zero repetitively, I get the following
(improved) results:
sd3:
Command overhead is 684 usec (time_4096 = 1264, time_8192 = 1843)
transfer speed is 7.06559e+06 bytes/sec
sd4:
Command overhead is 693 usec (time_4096 = 1264, time_8192 = 1836)
transfer speed is 7.16623e+06 bytes/sec
sd6:
Command overhead is 1038 usec (time_4096 = 1323, time_8192 = 1607)
transfer speed is 1.44067e+07 bytes/sec
Anybody have any ideas on what's happening here? Perhaps the disks
caching algorthms were designed to optimize sequential reads (e.g.,
emphasis on read ahead) rather than repetitively reading the same block
(which isn't too likely with a reasonable OS).
Thanks,
--
Bob Willcox Deliberation, n.: The act of examining one's bread
bob@luke.pmr.com to determine which side it is buttered on.
Austin, TX -- Ambrose Bierce, "The Devil's Dictionary"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970808111245.30561>