[TriLUG] OT: hd speed with 33MHz and 100MHz controller are the same

[Robert Dale]

On 6/12/07, Joseph Mack NA3T <jmack at wm7d.net> wrote:
> I have an old (200MHz dual Pentium Pro) computer with (I
> think) a 33MHz PCI bus (have no idea really).
>
> I have two disks -
>
> o original onboard disk controller connected to a 40G IDE
> disk (several years old) via and old style IDE ribbon
>
> o a 100MHz Promise controller in a PCI card connected to a
> new disk (bought yesterday) via one of the new style (twice
> as many wires) ribbon cables.
>
> I would have expected the new disk with the 100MHz
> controller to be much faster, but it appears to be the same
> speed as the older disk with the slower controller.
>
> My test is badblocks, which I'm running on both disks at the
> same time. Both disks are writing the same number of
> blocks/time (within a couple of 5). I get the same speed I
> move the disk on the PCI bus to an external USB 2.0
> enclosure attached to a USB 2.0 PCI controller.
>
> with hdparm
>
> # hdparm /dev/foo
>
> I get the same output for all devices (eg using_dma is on).
>
> Have I set it up the faster disk controller wrong, or is the
> slow 33MHz PCI bus determining the speed?
>
> (I would expect that badblocks doesn't send much over the
> PCI bus and it's all done by talking between the disk
> controller and the disk, but the load average is about 4 for
> 2 disks, so I guess the CPU is at least waiting for the
> disk, if not doing something itself).

The bus probably is 33MHz, 66MHz at most.  And it probably is the bottleneck.
Just as you wouldn't expect to Gb speeds on a 10baseT network just
because you plug in a GigE card.

badblocks probably sends quite a bit of data between the processor and
hd since it has to generate test data, write it to disk, then read it
back and compare.  This is how it tests for badblocks.  If you're
testing a 40gb drive, you'll end up writing 40gb and reading back
40gb.

A better benchmark would be to use something like bonnie++ [1] on each
disk separately and compare numbers.  It measures raw throughput
through various tests - it does not try to verify data like badblocks
(which potentially could be cpu bound).  You can also limit the size
of files.

[1]a http://sourceforge.net/projects/bonnie/
[1]b http://www.coker.com.au/bonnie++/

-- 
Robert Dale