JASON SNYDER wrote:
> I've run some not too scientific hard drive performance tests on my 800
> MHz Athlon (slot-A) and the results seemed pretty good, but not quite
> what I hoped for.
>
> Here is the system set up: Athlon 800 MHz CPU, one 256 MB stick of NEC
> PC133 RAM, ASUS K7V m/b (it has an Ultra66 controller built into the
> chip set among other niceties), In-Win Q500 case (full tower 300 W), a 4
> Meg Diamond Stealth 2000 3D PCI video (pretty old, but it doesn't matter
> too much with this system), a Promise Ultra66 PCI controller (on one of
> the PCI expansion slots), and a 10 GB IBM 14GXP on one bus and a 45GB
> IBM 75GXP one the other bus on the Promise controller. (The hard drives
> started on a machine that didn't have onboard UDMA and I never got
> around to changing to the onboard controller when I put this machine
> together. Plus, I have other niceties on the onboard controller that I
> would have to reconfigure if I moved.) Since the 10 GB drive can only
> handle UDMA33, I configured it by typing in the following and later
> adding to my startup files: hdparm -m16 -c1 -d1 -X66 /dev/hde. Seeing
> that I put the 45 GB drive on its own bus on the Promise controller, I
> did similar to the 10 GB drive except I typed in hdparm -m16 -c1 -d1
> -X68 /dev/hdg. (According to the man page if I read it right this
> should have set both drives to normal optimized setting plus the 10 GB
> drive has Ultra33 explicitly set and the 45 GB explicitly set to Ultra66
> mode.)
>
> I then ran hdparm -t /dev/hdx repeatedly on both drives. On the 10 GB
> drive, the measured rate usually hung around 13 MB/s. This is about
> where IBM said that the maximum drive performance should be at, so I was
> happy there. With the 45 GB drive, the measured rate usually hung
> around 24 MB/s. According to IBM the maximum x-fer rate of the drive is
> around 37 MB/s. I don't consider 24 MB/s bad for a current day system
> when doing a brute force reads without considering file system overhead
> or seek times, but it seems like I should be seeing more. It leaves the
> question open to what the bottleneck is. Just to cover a few
> possibilities, it could be that hdparm is not that accurate with the
> fastest of the fast IDE drives, a bottleneck in the kernel, a
> misunderstanding of how to use hdparm, a possible noisy cable forcing
> rates down to ultra33 without it being reported, and so on and so
> forth. It would be nice if someone with the know how could point out
> what is the most likely bottleneck or at least give test results that
> could give me clues on what it is probably not the bottleneck.
>
Hello
I have just upgraded to a dual Celleron running at 533 MHz wiyh a fronside
bus speed at 66 MHz (I am not allowed to overclock it) with 256 Mb 100MHz
ram. My disks are a Quantum fireball UDMA33 and a IBM 75GXP UDMA100. All
attached to a ABIT BP6 board with a HPT366 controller.
I have upgraded the Mandrake 7.1 kernel with the 2.2.27-0.21 to get support
for the bus, so now my system is (without the use of hdparm) running with a
transferrate of around 14,5 for the Quantum, and around 29 for the IBM.
How well is your controller supported by the kernel?
> Something else that I did was to run hdparm -T /dev/hdx multiple times.
> I saw values ranging from 55 MB/s to 128 MB/s. The results seemed to
> vary mostly with how much memory I had in use. Like when I didn't have
> much of anything in memory is when I saw rates like 55 MB/s. When I had
> a moderate amount in memory in use (like having X, SETI@home, Netscape,
> and a few other things loaded) is when I saw the higher rates all the
> way up to 128 MB/s. I haven't tried it yet with the memory jammed full
> of stuff. (It takes too long to fill up 256 MB of RAM under Linux at
> the moment for me).
In my opinion this value is of pure academic interest
Mogens J�ger
