[plug] idebus speed
Craig Ringer
craig at postnewspapers.com.au
Sun Oct 17 14:26:10 WST 2004
On Sun, 2004-10-17 at 14:04, Steve Boak wrote:
> If your drive is /dev/hda for example, try 'hdparm -Tt /dev/hda' which will
> give you the cache and real transfer rates for your drive. This is very
> useful to measure any improvements as you try different settings.
Agreed, though do remember that it's a very primitive measure and
probably does not reflect real-world drive performance - except maybe
simple linear reads without filesystem interaction.
Another tool that may be of interest to obsessive tuners is `blockdev`.
Finally, if you do feel the need to do more realistic benchmarking (say,
if you're trying to tune a file server) consider looking into iometer
and bonnie++ . I seem to recall some Apache and Samba-based benchmarks
too, but I've never cared enough to look into them.
Finally, remember that disk throughput is not everything. Sometimes it
can come at the cost of request latency - meaning that while your disk
transfers more data, the time gap between something asking for data and
receiving it is longer. That will seem to make most interactive tasks
SLOWER not faster, even though by one common measure the disk is working
faster.
Yes, I realise the original post wasn't really about this, but it seems
worth mentioning given that he's looking into disk performance issues.
> As a reference, here's my results for a Via motherboard that I *know* IDE
> interrupts don't work on, no matter what hdparm settings I use:
> Timing cached reads: 196 MB in 2.03 seconds = 96.55 MB/sec
> Timing buffered disk reads: 12 MB in 3.17 seconds = 3.79 MB/sec
Also for comparison, results from a fairly fast 72k RPM 120GB disk in my
home desktop:
/dev/hdb:
Timing buffer-cache reads: 1288 MB in 2.00 seconds = 644.00 MB/sec
Timing buffered disk reads: 154 MB in 3.03 seconds = 50.83 MB/sec
Please note that for most uses only the buffered disk reads number
actually matters.
--
Craig Ringer
More information about the plug
mailing list