[Techtalk] hdparm ?
Travis Casey
efindel at earthlink.net
Mon Apr 12 21:48:09 EST 2004
On Sunday 11 April 2004 22:16, ed orphan wrote:
> Somebody who claims to be an expert told
> me that using hdparm would significantly
> improve hard drive performance.
> Sounded good to me, so I took a look at
> the man file for hdparm. Confusing indeed,
> and alarming! So many of the options are
> labelled "dangerous" and "use with caution".
> Does hdparm make a big improvement for
> hard drive performance. I've got an 80 Gig
> Western Cavier.
> Can anyone advise me on what parameters
> to use that won't destroy the computer?
Sure. There's been a lot of scary talk so far, but here's what's worked for
me in the past. Ideally, you should do these in single-user mode, so you
can be sure that there's no confounding factors.
start with:
hdparm -v /dev/hda
This will give you a brief summary of the current settings of the parameters
you're most likely to want to touch, like so:
lostthoughts:~# hdparm -v /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 7297/255/63, sectors = 117231408, start = 0
Note that each one has some explanatory text as well.
Now let's test your transfer speed:
lostthoughts:~# hdparm -Tt /dev/hda
/dev/hda:
Timing buffer-cache reads: 724 MB in 2.00 seconds = 362.00 MB/sec
Timing buffered disk reads: 130 MB in 3.00 seconds = 43.33 MB/sec
Not bad at all. Note that these are read-only tests, and you haven't
changed anything yet, so this shouldn't hurt anything.
Since that drive's already pretty well optimized, let's try another one:
lostthoughts:~# hdparm -v /dev/hdb
/dev/hdb:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 4865/255/63, sectors = 78165360, start = 0
lostthoughts:~# hdparm -Tt /dev/hdb
/dev/hdb:
Timing buffer-cache reads: 872 MB in 2.00 seconds = 436.00 MB/sec
Timing buffered disk reads: 94 MB in 3.02 seconds = 31.13 MB/sec
Okay. So this one's using 16-bit IO. We might be able to get a performance
boost if we put it to 32-bit.
lostthoughts:~# hdparm -c 1 /dev/hdb
/dev/hdb:
setting 32-bit IO_support flag to 1
IO_support = 1 (32-bit)
Now we'll test again:
lostthoughts:~# hdparm -Tt /dev/hdb
/dev/hdb:
Timing buffer-cache reads: 900 MB in 2.00 seconds = 450.00 MB/sec
Timing buffered disk reads: 98 MB in 3.08 seconds = 31.82 MB/sec
Not a really big improvement... maybe 5% in cached, hardly any at all in
actual disk reads. Let's try setting it to 3 (w. sync) and test:
lostthoughts:~# hdparm -c 3 /dev/hdb
/dev/hdb:
setting 32-bit IO_support flag to 3
IO_support = 3 (32-bit w/sync)
lostthoughts:~# hdparm -Tt /dev/hdb
/dev/hdb:
Timing buffer-cache reads: 864 MB in 2.00 seconds = 432.00 MB/sec
Timing buffered disk reads: 88 MB in 3.06 seconds = 28.76 MB/sec
The "3" is required by some chipsets; it's a bit slower, but safer. Neither
one made a big difference, though, so I'll just turn it back off on this
drive:
lostthoughts:~# hdparm -c 0 /dev/hdb
/dev/hdb:
setting 32-bit IO_support flag to 0
IO_support = 0 (default 16-bit)
Okay. So, where are those big speed improvements? Well, I've already done
some tuning on this box, so let's turn some of those things off...
lostthoughts:~# hdparm -d 0 /dev/hdb
/dev/hdb:
setting using_dma to 0 (off)
using_dma = 0 (off)
lostthoughts:~# hdparm -Tt /dev/hdb
/dev/hdb:
Timing buffer-cache reads: 868 MB in 2.00 seconds = 434.00 MB/sec
Timing buffered disk reads: 14 MB in 3.31 seconds = 4.23 MB/sec
Now *that's* a big difference. Roughly five times slower without DMA!
Let's try turning DMA back on, and setting the multcount to off:
lostthoughts:~# hdparm -m 0 -d 1 /dev/hdb
/dev/hdb:
setting multcount to 0
setting using_dma to 1 (on)
multcount = 0 (off)
using_dma = 1 (on)
lostthoughts:~# hdparm -Tt /dev/hdb
/dev/hdb:
Timing buffer-cache reads: 904 MB in 2.00 seconds = 452.00 MB/sec
Timing buffered disk reads: 98 MB in 3.04 seconds = 32.24 MB/sec
Note that nothing effects cache reads much. It's about the same without
multcount as before, but I'm going to set it back anyways.
lostthoughts:~# hdparm -m 16 /dev/hdb
/dev/hdb:
setting multcount to 16
multcount = 16 (on)
Why am I using 16? The drive can tell you what the maximum multiple sector
count it supports is:
lostthoughts:~# hdparm -i /dev/hdb
/dev/hdb:
Model=IC35L040AVER07-0, FwRev=ER4OA41A, SerialNo=SXDSXLA6483
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 *udma4 udma5
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1:
* signifies the current active mode
This gives you a lot of information, including what DMA mode is being used,
the maximum multiple sector count the drive supports, and other stuff.
Looking at /dev/hda just for comparison:
lostthoughts:~# hdparm -i /dev/hda
/dev/hda:
Model=WDC WD600BB-00CAA1, FwRev=17.07W17, SerialNo=WD-WMA8F1286179
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=117231408
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2
AdvancedPM=no WriteCache=enabled
Drive conforms to: device does not report version:
* signifies the current active mode
For extra fun, -I checks the current settings (-i uses the ones detected at
boot time), and has a different format, to make things more fun:
lostthoughts:~# hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: WDC WD600BB-00CAA1
Serial Number: WD-WMA8F1286179
Firmware Revision: 17.07W17
Standards:
Supported: 5 4 3 2
Likely used: 6
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 117231408
device size with M = 1024*1024: 57241 MBytes
device size with M = 1000*1000: 60022 MBytes (60 GB)
Capabilities:
LBA, IORDY(can be disabled)
bytes avail on r/w long: 40 Queue depth: 1
Standby timer values: spec'd by Standard, with device specific
minimum
R/W multiple sector transfer: Max = 16 Current = 16
Recommended acoustic management value: 128, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
Write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
* Device Configuration Overlay feature set
Automatic Acoustic Management feature set
SET MAX security extension
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
Personally, I've found that turning on DMA is the most useful thing; I
haven't seen it cause a problem in and of itself, and it increases transfer
speeds greatly, as seen above. What I have seen cause problems sometimes
is trying to set DMA to a higher-performance mode, via the -X flag.
I'd suggest messing with hdparm right after setting a system up, before you
have anything important on it -- that way there's less to worry about if
you do manage to muck up the drive. Note that hdparm settings aren't kept
across a powerdown... so if you want to keep settings, you'll need to make
an init script to set them again after each bootup.
These are pretty much the only settings I've messed with, other than using
-X once to set a lower DMA mode on a system where turning on DMA made the
drive unreliable -- the system would lock up with the drive light randomly,
usually ten to thirty minutes after booting. Thankfully, I didn't lose
anything, and had backups in any case.
After messing with hdparm, keep an eye on the system logs for disk errors
for a while.
I wouldn't recommend messing with the other settings. As the hdparm man
page will tell you, a lot of them are dangerous... and my experience in
testing is that most of them will make very little difference in drive
speed. DMA is the big one.
Unmasking IRQs sounds good... but as the man page warns, it can be
dangerous, and my experience is that it doesn't help much. Indeed, I've
found that turning on DMA when it's off helps a lot more there as well,
since doing the transfers ~5 to 10 times as fast naturally means that the
other IRQs are masked off for less time, and the increased disk
responsiveness helps a lot of other things.
--
|\ _,,,---,,_ Travis S. Casey <efindel at earthlink.net>
ZZzz /,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)
More information about the Techtalk
mailing list