Quoting tim hall <tech@xxxxxxxxxxxxxxxxxxxxxxx>: > 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 drive. 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 -m16. 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. =MB= -- A focus on Quality.
