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.