On Oct 18, 2:43pm,
plug@arcticmail.com wrote:
> You might give "bonnie" a whirl...
Good idea... I've tried to write up a fairly complete report below.
In order to do so, I've repeated some of the info of my mail of
yesterday.
...........................................................................
About Bonnie
------------
For those of you who don't know, the ``bonnie'' program is used to test
filesystem performance on Unix systems. See
http://www.textuality.com/bonnie/
I had used bonnie once in the distant past and the trick to using
it and getting meaningful numbers is to specify a file size which
is at least twice as large as your memory. Also these tests take
longer to run, which is why I used the ad hoc tests of yesterday.
The bonnie documentation at
http://www.textuality.com/bonnie/advice.html
suggests that the file size be four times the size of your memory.
This turned out to be impossible to do, however, since the test
machine has 1GB or memory and because it's an x86 box which limits us
to 2GB files. The ``bonnie'' docs suggest using a value of 2047 MB in
this case. So that's what I did, even though this value is slightly
less than twice the memory size on this machine. I have a number of
applications running though and ``free'' reports 739696 KB of memory
free after discounting the space used for the disk buffer cache.
The command that I used to run these tests was
Bonnie -s 2047 -m NAME
where NAME was one of scsi, ideraid1, or ide depending upon which
partition my current directory was on when I ran the test.
The test machine
----------------
These tests were performed on a dual PIII 550 box with 1GB of memory.
This machine has both an Adaptec AIC-7890 Ultra2 SCSI host adapter as
well as Promise Ultra66 ATA/66 controller. The SCSI controller should
be faster since it is capable of transferring data at 80MB/sec as
opposed to 66MB/sec for the Ultra66. Also, I've enabled tagged
command queuing with a depth of 8 for the SCSI drive. (TCQ was
disabled in the tests that I reported yesterday.)
I'll now describe the drives...
The SCSI drive
--------------
The SCSI drive is a Quantum QM318000TD-SW. This is a drive in Quantum's
Atlas III product line. It's a little over a year old and the specs
are as follows:
7,200 RPM, 7.8 ms average seek time, 180 Mb/sec internal transfer
rate, up to 80 MB/sec transfer rate, Ultra2 SCSI (LVD) or Ultra
SCSI interface
This is from:
http://www.quantum.com/products/archive/atlas_iii/atlas_iii_features.htm
Later on the this same page, it also claims that this drive is capable
of a sustained transfer rate of 12MB/sec. (This is roughly the number
that I reported from the ``hdparm -t'' test of yesterday.)
There are more detailed specs at
http://www.quantum.com/products/archive/atlas_iii/atlas_iii_specs.htm
The IDE drives
--------------
The two IDE drives are Western Digital Caviar WD450AA. On paper, these
drives should perform worse than the SCSI drive:
5400 RPM, 9.5 ms average seek time, 177.54-300.98 Mb/sec internal
transfer rate, up to 66 MB/sec transfer rate using Mode 4 Ultra ATA.
I couldn't find a claim for an average sustained rate in the product
literature. (I could for the high performance SCSI drives though. My
theory is that if they told you what this number was for the rest of
their drives, you might be disinclined to buy the more expensive
ones.)
Bonnie results
--------------
Here are the results. I have more to say about them below.
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
scsi 2047 5132 86.1 3903 5.2 3914 6.9 5194 79.5 7898 8.2 100.6 2.3
scsi 2047 5448 93.7 3977 5.2 3930 6.6 5189 80.0 7854 8.3 100.7 2.3
ideraid1 2047 6022 99.7 20761 18.9 8459 11.8 6392 97.0 17793 14.9 249.6 4.2
ide 2047 6036 99.5 28333 25.2 9786 13.3 6420 96.1 19831 14.7 145.8 1.5
Making sense of the numbers
---------------------------
First, note that I ran the tests on the SCSI drive twice. (The
results were so bad that I felt compelled to run it again.)
I think the "Per Char" numbers are pretty much meaningless unless you
program with getc() and putc() all of the time. The reason that these
are so bad is that it's mostly CPU bound; you're really testing
function call performance. IMHO, the ones to focus on are the "Block"
numbers for input and output. The "Rewrite" and "Seeks" numbers are
significant too, particularly for database applications. (For most of
the applications that I run, I'm interested in read and write
performance.)
In terms of sustained write performance, the IDE RAID-1 device
outperformed SCSI by a factor of 5. The IDE drive without the RAID
overhead outperformed the SCSI drive by over a factor of 7.
The numbers are somewhat closer for reading from the drive. The
IDE RAID-1 device only outperformed SCSI by a factor of 2.25. When
we use the raidless IDE partition, this increases to 2.51.
The rewrite numbers show a similar performance advantage for both
the IDE RAID-1 and plain IDE over SCSI: 2.15 and 2.49 repectively.
The surprising numbers are the random seek performance in which the
IDE RAID-1 device actually does better than the plain IDE partition.
But in both cases, they still outperform the SCSI drive by factors
of 2.48 and 1.45 respectively.
In summary, the IDE RAID-1 solution outperformed the SCSI drive
by at least a factor of two in all tests. This is rather surprising
since the SCSI drive would appear to be the faster drive on paper.
(text/plain)