« WOW, snagged a Kurobox on eBay | Main | Router Upgrade - USR8200 »
February 28, 2006
Kurobox tweaks - using hdparm to squeeze out speed
So.. My mp3 archive got corrupted on hercules.. again!!!
Dunno what happened, but when I powered off the external USB hard drive the machine went bonkers.
I've always felt Linux and USB do not mix well. At least in the 2.4.20ish tree.
Even USB on the Kuro is pretty dam slow.
Never thought it would affect the other scsi subsystems though..
Lo and behold my 300GB mp3 archive filesystem ended up being 1 large 300GB file.
No system. wtf!
So I break down, format and get down to rsyncing the files back from the Kurobox. (kuro 1 of 2).
The throughput is about 4MB/s and will take ages to move the 300GB of files.
So I logon to the Kuro and start tweaking vm and hdparm.
The magical settings for hdparm bumped up the rsync from 4Mb/s to a peak of 6-7Mb/s.
My init script follows.
#!/bin/sh
# set stop time for hdd spindle moter
if [ -x /sbin/hdparm ] ; then
/sbin/hdparm -S 241 /dev/hda
/sbin/hdparm -c 1 -d 1 -a 16 -m 16 /dev/hda
fi
Normally the drives are already enabled for DMA. (-d 1).
I added -c 1 for 32 bit i/o on the pci buss.
-m 16 for multicount transfers (i.e. 16 sectors are transfered at a time from drive to ide bus)
-a 16 for readahead buffering internal to the drive's cache.
I think it was the -a 16 that did it as the other settings were already present.
I doubt I'll be able to improve write performance without turning on write caching.
When I get a chance I'll redo some benchmarks on the 1GB network to see how much I can squeeze out of the kuro.
Right now hercules is still on the operating table and not hooked up to the 1GB switch.
Posted by Me on February 28, 2006 09:35 AM
Comments
Also, would the "-d1 -X##" and "-m##" options have any use here? Are these outdated, or would they manage to provide some sort of boost? Or would that end up being overkill?
Yes, this is all new to me. I'm learnin' dang it! :P
RTFM. Never mind. I wonder if there's a man page for this that isn't 10 years old, though (the one I found was from Jul 30, 1996). Good stuff to know. Good I'm a newb. :P
No need for the -X parms. The system comes up running in the proper UDMA mode.
FWIW, here's the HDPARM output
root@kuro1 ~ $hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 5A300J0, FwRev=RAMB1TV0, SerialNo=A80VDTTE
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=268435455
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 udma0 udma1 udma2 udma3 udma4 *udma5 udma6
root@kuro1 ~ $hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
I/O support = 1 (32-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 16 (on)
geometry = 36473/255/63, sectors = 585940320, start = 0
root@kuro1 ~ $hdparm -Tt /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.13 seconds =113.27 MB/sec
Timing buffered disk reads: 64 MB in 1.48 seconds = 43.24 MB/sec
Well, didn't do a whole lot. Here's what I got:
Before:
root@LINKSTATION:/# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.15 seconds =111.30 MB/sec
Timing buffered disk reads: 64 MB in 1.57 seconds = 40.76 MB/sec
root@LINKSTATION:/# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.14 seconds =112.28 MB/sec
Timing buffered disk reads: 64 MB in 1.51 seconds = 42.38 MB/sec
root@LINKSTATION:/# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.15 seconds =111.30 MB/sec
Timing buffered disk reads: 64 MB in 1.53 seconds = 41.83 MB/sec
root@LINKSTATION:/# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.14 seconds =112.28 MB/sec
Timing buffered disk reads: 64 MB in 1.53 seconds = 41.83 MB/sec
After:
root@LINKSTATION:~# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.14 seconds =112.28 MB/sec
Timing buffered disk reads: 64 MB in 1.54 seconds = 41.56 MB/sec
root@LINKSTATION:~# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.15 seconds =111.30 MB/sec
Timing buffered disk reads: 64 MB in 1.52 seconds = 42.11 MB/sec
root@LINKSTATION:~# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.14 seconds =112.28 MB/sec
Timing buffered disk reads: 64 MB in 1.55 seconds = 41.29 MB/sec
root@LINKSTATION:~# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.13 seconds =113.27 MB/sec
Timing buffered disk reads: 64 MB in 1.51 seconds = 42.38 MB/sec
root@LINKSTATION:~# hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
I/O support = 1 (32-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 16 (on)
geometry = 30401/255/63, sectors = 488397168, start = 0
root@LINKSTATION:~# hdparm -i /dev/hda
/dev/hda:
Model=SAMSUNG SP2514N, FwRev=VF100-33, SerialNo=S08BJ1GYC19050
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=268435455
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 udma0 udma1 udma2 udma3 udma4 *udma5
-Packgrog
Fascinating! If you do actually end up getting numbers for a performance improvement, it may be worth writing it up for the Kuro and Linkstation Wiki's. I still haven't grown the cohones (or really had the time and mental devotion while sick) to try upgrading the firmware in my HG250 Linkstation yet. Once I do, I may just try this out. I REALLY want to see if I can track down temperature controlled fan speed script I saw out there again, as the fan is noticable when everything else is off. I haven't bothered with a USB piggy-back yet.
On a side note, Apple has released a Core Duo-based Mac Mini. Slick! I wonder what the power draw on that sucker is, though. The Intel Dual cores eat a lot more power than the AMD's (for the moment).