Steelbytes.com HD_Speed

[backshooter]

Had an odd experience with this hdd benchmarking utility. I dl it to test an external USB 2.0 enclosure+hdd, after reading about it on Chris Chandler's Quantex support site (my pc's aren't Quantex however).

On one of my pc's (the original one I used to initialize the hdd, a wdse 160GB), HD_Speed performed as expected, benchmarking the enclosure+drive @ ~10--12 MB/s on the first and last partitions of 5.

When I switched the USB drive to a second pc to back up some files on it, HD_Speed could only 'see' the floppy and cd drives! It couldn't see the internal ide drive, the RAID 0 (2 ide drives attached to a FastTrak66 PCI controller), or the USB drive. Needless to say I was unable to benchmark anything on this pc using HD_Speed. I quite out of it and relaunched just to be sure.

The external USB drive functioned as expected, though it felt a bit sluggish as compared to how it worked on the first pc (this pc has a different, 'no-name' USB 2.0 PCI adaptor). I'm going to try out  HD Tach 2.7 to make a comparison.

Both pc's are running W2KSP3. The first one has two internal ide's (master/slave) and a master cd burner running off the mobo, but no RAID.

[backshooter]

OK I guess that experience was an anomaly because I just ran HD Speed flawlessly on the 'problem' pc, and confirmed the read speeds I got with HD Tach (the freeware version doesn't support write tests). It recognized and benchmarked all drives including the 'plain vanilla' ide, the RAID 0 and the USB 2.0 enclosure+drive.

Interestingly the USB drive benchmarked substantially faster than on the 'first' pc, @ 13/17 MB/s read/write. On the first one it was 10/12 MB/s. (since the write benchmark of HD Test is destructive, needless to say I did not run it on my data-packed internal drives)

There was no significant variation among various partitions tested.

In comparison the RAID 0 benchmarked read @ 40MB/s and the plain ide (ATA 33 I believe) @ 20MB/s.

So, not too shabby...

[Chandler]

As for variation between PCs.  I have seen this too, even when using the same USB 2.0 card (a Cardbus).

I have found that it is down to the PCI Latency timer setting for the USB 2.0 controller which greatly affects speeds.  My laptop defaults to a latency timer of 0 clk for the Cardbus bridge and all devices on the Cardbus bus (which is basically a secondary PCI bus) - this gives dreadful benchmarks scores - maximum of around 5MB/s!  Changing this to 32clk ramps it up to 12-13MB/s.  This is with an NEC controller based card, and it is a very early design.

Newer USB 2.0 controllers, such as those built into modern motherboard chipsets will probably give superior performance.

[backshooter]

Interesting. I optimized the Latency to 64 in the K7M bios, to minimize 'infinite sound loop' lockups caused by my SBL and via southbridge. I guess on the AZ11 (KT133) it's at the default (32?).

The other difference is the K7M has a slot TB 900, the AZ11 a (socket) Duron 600. I've read elsewhere that the cpu is a factor in USB 2.0 performance.

[Chandler]

CPU speed is possibly another factor.  On my 1.2GHz system I have seen it climb up to 40%-50% when doing USB 2.0 transfers.  Memory throughput is also critical.