Re: [linux-audio-user] APIC is bad? What about hdparm?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] APIC is bad? What about hdparm?
From: Malcolm Baldridge (
Date: Sat Jul 17 2004 - 14:53:05 EEST

Quoting tim hall <>:

> Last Friday 16 July 2004 18:47, Chaz Worm was like:
> > Speaking of disagreements, I've seen two groups of thought on using
> > 'hdparm' to speed up a hard drive. What is the final verdict?
> I've only come across the POV that it's essential for glitch-free
> recording.

If your kernel does not choose an appropriate Bus Mastering tuning parametre
for the hard disk drive, it is vital you tune the IDE drivers to at least
use Bus Mastering DMA and to release IRQs earlier with -u1.

As for whether it's worthwhile or not to setup -m16 (as 99% of the modern
HDDs support), that is more debatable.

At the very least, the following will tune your IDE driver to make use of
Bus Mastering DMA, early-release of IRQs, and to ensure 32-bit I/O access [a
nebulously and under-documented function]:

hdparm -u1 -c1 -d1 /dev/hda

Where we leave the realm of easily verifiable results is whether or not to
extend the above hdparm command to:

hdparm -u1 -c1 -d1 -m16 /dev/hda

I don't see any (large) improvements in hdparm -t -T /dev/hda benchmarks,
for example. I've seen throughput benchmarks slightly improve with low -m
settings, like -m1 and -m8

Since this is a multi-sector transfer unit setting, it's conceivable that a
large blast of contiguous sector reads/writes could hold off further device
channel commands and thereby "block" other read/writes queued up behind the

It's possible. But keep in mind that 16 sectors sounds like alot, but in
UDMA-100 time, that's 0.08ms of time on the wire per transfer unit.

Even assuming the drive has to wait for the sectors to arrive or empty out
of cache, and lets assume the drive's a slow dog, 20Mbytes/second, that's
still only 0.4ms of time per atomic transfer unit.

If you're "on the borderline" with xruns, you might gain something by tuning
your IDE driver with a smaller or larger -m setting. Try -m1, -m4, -m8, or

Finally, this may sound weird and voodoo, but make sure your IDE cables
aren't too twisted or molested. Cable CRC errors do happen and they cause
abrupt transfer speed aberrations.

If you install smartmontools (S.M.A.R.T. drive logging/diagnostic tool), you
can inquire of cabling CRC errors and note whether or not you seem to be
getting alot of them in your system.

I have yet to meet a post-440FX (Pentium era) chipset whose Linux IDE driver
'sperformance was not radically improved with a massive reduction in CPU
utilisation during heavy disk I/O when the IDE driver was tuned with -c1 -u1
-d1 versus one which was NOT tuned. -c1 may not provide any tangible
benefit, but -d1 definitely does, and -u1 gets you released from
IRQ-hold-off states within the driver a bit earlier. Modern kernels built
with specific IDE chipset support are doing a better job of configuring
these with good defaults. Verify it with: hdparm -v /dev/hda

If anyone tells you -d0 is a better tuning, I would be extremely skeptical.
 There are some wickedly buggy chipsets out there, but most of the really
vile ones aren't in systems you're likely to use for a DAW.

By the way, all of the above only applies to IDE drives. SCSI drives don't
need any of this hand-waving.


A focus on Quality.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Jul 17 2004 - 14:56:51 EEST