# Hard Drive Performance

## Riftwing

I'm getting this hard drive performance problem.

I do hdparm -Tt /dev/hda and get

```
/dev/hda:

 Timing buffer-cache reads:   128 MB in  0.50 seconds =256.00 MB/sec

 Timing buffered disk reads:  64 MB in 14.56 seconds =  4.40 MB/sec

```

Which is pretty bad so I do hdparm /dev/hda and I get

```
/dev/hda:

 multcount    = 16 (on)

 IO_support   =  0 (default 16-bit)

 unmaskirq    =  0 (off)

 using_dma    =  0 (off)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    =  8 (on)

 geometry     = 9732/255/63, sectors = 156355584, start = 0

```

So I do hdparm -d 1 -c 1 -k 1 /dev/hda and do hdparm -Tt /dev/hda and get much better results

```
/dev/hda:

 Timing buffer-cache reads:   128 MB in  0.49 seconds =261.22 MB/sec

 Timing buffered disk reads:  64 MB in  1.60 seconds = 40.00 MB/sec

```

but as soon as I do anything they go back to the old settings. Also my hard drive can do udma 6 but when i set it to udm6 in bios I get a read error when loading grub. I know my hard drive can do udma 6 because when I do hdparm -i /dev/hda, I get 

```
/dev/hda:

 Model=MAXTOR 6L080J4, FwRev=A93.0300, SerialNo=364124826253

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }

 RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4

 BuffType=DualPortCache, BuffSize=1820kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156355584

 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 udma3 udma4 *udma5 udma6 

 AdvancedPM=no WriteCache=enabled

 Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1:  1 2 3 4 5

```

 But I noticed in hdparm -I /dev/hda I noticed at the top it says

```
Standards:

        Used: ATA/ATAPI-5 T13 1321D revision 1 

        Supported: 5 4 3 2 & some of 6

```

 I'm guessing thats talking about what udma settings are supported but what do they mean by some of 6?

Thank you.

----------

## bsolar

I don't know if this is relevant to your problem but I had a similar problem because of a kernel misconfiguration.

Enabling the right chipset allowed the kernel to find and set dma at boot.

----------

## AlterEgo

UDMA 6 is ATA133, right ?

You don't really need it. The performance difference compared to ATA 100/UDMA 5 is close to zero.

Your harddisk's data-throughput just isn't fast enough: you're not even getting close to 100MB/s data transfer (uncached).

Don't worry about it.

----------

## Matje

Do like I do... Put the hdparm in your /etc/conf.d/local.start to enable dma, 32 bit. You can also, like bsolar said, enable dma at boot by enabling some kernel option, I have that now, but it doesn't make a real difference if you do it at kernel time or at init-scipt time, since the init scripts mostly are simple ones that don't use the hard drive intensly...

----------

## Riftwing

I found the problem... I'm using a VIA chipset and via82xxx wasn't enabled and now it is enabled dma by default. In order to do this I needed to emerge gentoo-sources 2.4.20-r1 since it had the new verison of that module since the verison in 2.4.19-r10 didnt work (maybe because I'm using the new KT400 chipset?). Now at kernel boot-up im getting 

```
XFS mounting filesystem ide0(3,2)

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

ide0: reset: success

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

ide0: reset: success

Ending clean XFS mount for filesystem: ide0(3,2)

VFS: Mounted root (xfs filesystem) readonly.

Mounted devfs on /dev

```

 Any ideas?

----------

## Malakin

Try vanilla sources. 2.4.20 has support for kt400 and I know it works.

----------

## s003apr

i also have been using the 8235 chipset and while the newer kernel (vanilla 2.4.20) has fixed my harddrive DMA problems, It has made my cd-rom and cd-rw suck.

I was wondering If any of you guys experienced similar problems.

Here's my thread

https://forums.gentoo.org/viewtopic.php?t=33140

----------

## maxmc

I used to have a working DMA but no it just goes:

```
27 max # hdparm -d 1 /dev/hda

/dev/hda:

 setting using_dma to 1 (on)

 HDIO_SET_DMA failed: Operation not permitted

 using_dma    =  0 (off)

```

Could I have changed something inapropriate in the kernel config when I removed my soundcard.. ah dam...

----------

## Malakin

 *Quote:*   

> I used to have a working DMA but no it just goes:

 

If you configure your kernel properly you shouldn't have to use hdparm. Enable support for your chipset and enable dma by default. If hdparm isn't working then you probably don't have support for your chipset in the kernel.

----------

## maxmc

I said IT USED TO WORK!

Now it doesnt..

----------

## snowmoon

One thing to note gentoo comes with a "set all hd's to DMA" rc-script, but it's not set executable so rc-update doesn't like it.

chmod 755 /etc/init.d/hdparm

rc-update add hdaprm default

----------

## patkc66

 *Malakin wrote:*   

> Try vanilla sources. 2.4.20 has support for kt400 and I know it works.

 

I tried that on my KT333 based machine, and I can lock the hard disk controller up at will. (Mounting  /dev/vg/usrcopy to /mnt/vg/usr and then running cp -ax /usr /mnt/vg will do it every time.)  The one time I was able to get it to log a disk error, it was a SeekComplete error.  Most of the time though, by the time things have gone south, it takes the logger with it.

I'm thinking I might need to try to back off the default hdparm settings to something a little more conservative and see how far I can push it before things go crunch again.   It always amazes me how many odd situations benefit from a judicial application of the standard binary search algorithm.  :Smile:  I guess I'm going to see if this is one of those.

I guess this is kind of like the old method of adjusting a carbeurator on a car: keep adjusting the mixture until the engine starts to run rough again and then back it off a little.

By the way, when I tried the ac-sources, (2.4.21something) it made it as far as the login prompt (without X enabled) and then hung up.  And when I reset the machine and booted to the 2.4.19 kernel, something had replaced my modules.conf file with some reformatted version of my fstab file.  All my lvm directories were unreadable as a result.  I did find I had a modules.conf.old though so after copying it over the modules.conf and rebooting again, I was able to see the other logical volumes again.  Whew.  That was a close one.  Anyway, the lesson I think I came away from that little warning experience was not to experiment with new kernels until you have a decent backup and can afford to reload everything.    :Smile: 

Oh, one more thing.  I even took the vanilla 2.4.19 kernel and upgraded the via82cxxx.c module to 3.35 by itself and the lockups still happen, so whatever is causing the trouble is in that file or the chipset itself somewhere. 

Any other suggestions in the meantime?

----------

## patkc66

As I thought, it is stable if I back off the hdparm -X settings from the fastest settings it finds when it boots up.   On one disk, (A Western Digital WD136AA), I could only push it as far as -X 65 (UDMA Mode 1).   That's ok though.  As a result of all of this, I've moved all the information off of that disk onto the other one and switched them so it's /dev/hdb now.

The really good news was /dev/hda (a Maxtor 6Y120P0) though.  I was able to push it all the way up to -X 68 and still copy my whole /usr partition over to another fresh reiserfs partition and it worked without a hitch. 

Here are the results I'm able to get now, and things are very much happier.

```
# hdparm -tT /dev/hda

 

/dev/hda:

 Timing buffer-cache reads:   128 MB in  0.46 seconds =275.86 MB/sec

 Timing buffered disk reads:  64 MB in  1.34 seconds = 47.69 MB/sec

# hdparm -tT /dev/hdb

 

/dev/hdb:

 Timing buffer-cache reads:   128 MB in  0.45 seconds =283.81 MB/sec

 Timing buffered disk reads:  64 MB in  3.23 seconds = 19.82 MB/sec

```

 :Cool:   :Very Happy: 

----------

## mjoswig

 *snowmoon wrote:*   

> One thing to note gentoo comes with a "set all hd's to DMA" rc-script, but it's not set executable so rc-update doesn't like it.
> 
> chmod 755 /etc/init.d/hdparm
> 
> rc-update add hdaprm default

 

Actually there is something in the docs saying to put that into runlevel boot, not default. Have done that without chmod and it does work...

----------

