HOWTO: Speed Up Your Hard Drives

[Zeroangel]

I am trying to understand this, When I first tested to see my current speeds

$ sudo hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 156301488, start = 0

$ sudo hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 1488 MB in 2.00 seconds = 743.67 MB/sec
Timing buffered disk reads: 96 MB in 3.01 seconds = 31.91 MB/sec

then I made the changes:

$ sudo hdparm /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 = 256 (on)
geometry = 65535/16/63, sectors = 156301488, start = 0

$ sudo hdparm -tT /dev/hda
/dev/hda:
Timing cached reads: 1084 MB in 2.00 seconds = 541.14 MB/sec
Timing buffered disk reads: 84 MB in 3.06 seconds = 27.48 MB/sec

Am I reading this wrong? It looks like I am loosing performance by enabling multicount and IO_support.

According to this guide. Multicount is supposed to fetch several sectors at once reducing operating system overhead on disk I/O. While typically increasing speed (in your case, it does not, but it probably saves on your CPU).

Don't take that guide's opinion as gold though, I did look around, and although that guide's author seemed to be recommending MDMA2 mode, I found that it was vastly inferior to UDMA (which is multiword as well). As well as that author was also seemingly recommending that IO/Support be set to "3" or 32-bit w/synch -- which is slower (but works better with broken chipsets.)

I personally have enabled umaskirq and have all the other settings.

My /dev/hda entry in /etc/hdparm.conf looks as follows

/dev/hda {
    mult_sect_io = 16
    write_cache = on
    dma = on
    lookahead = on
    io32_support = 1
    interrupt_unmask = on
    transfer_mode = 69
}

And the speed tests report

 Timing cached reads:   382 MB in  2.01 seconds = 190.30 MB/sec
 Timing buffered disk reads:  222 MB in  3.00 seconds =  73.98 MB/sec

Which is rather fast for me!

[finite9]

according to hdparm manpage, 32bit IO support *is only relevant for disks not connected by standard ribbon cable* ie disks attached to external cables etc.

enabling 32bit support on standard internal hard drive has no effect on performance because the ATA spec. only supports 16bit on the ribbon cable. Have you run sudo hdparm -Tt /dev/hda 2 or 3 times on the drive with and without 32bit IO support? was there any difference?

[Zeroangel]

I've ran a few speed tests with 32-Bit I/O enabled and disabled. My hard drive is a rather new Seagate 7200rpm IDE drive.

The speed tests seem to confirm that you are right, that the 32-Bit I/O setting makes no difference on devices connected via IDE (ribbon) cable.

Additionally, i've also tested multi-sectoring and interrupt unmask features of the drive. Enabling them doesnt seem to make a real difference as far as pure HD speed is concerned, at least for my drive. It may possibly reduce OS overhead on reading the drives, but I couldnt determine that from the speed test alone.

[bodhi.zazen]

Nice How-to

This thread has been added to the UDSF wiki.

SpeedUp_HardDrive

If you do a major update to your how-to please send me a PM. Either I can teach you how to add to the wiki or I can try to maintain the wiki myself (as time allows), thank you.

Peace be with you,

bodhi.zazen

[tgalati4]

Maybe it's just me, but over the years I have experimented with hdparm tweaks and I find that most common Linux distros automatically pick the correct disk access mode and therefore the fastest disk speeds. Any tweaks beyond that are marginal increases. No real performance gains.

You will get a performance gain with more RAM and a faster (say 7,200 rpm) disk drive. With enough RAM you can set up some distros to run completely in RAM or set up RAMdisks that will speed up certain applications--audio/video or photo editing.

I'm more amazed at Ubuntu's ability to keep running even with bad hdparm parameters--more power to the stability of Linux.

[Terry of Astoria]

I'm posting this help request as a reply to this thread since it contains a couple of bits that may be of interest to the HOWTO maintainer. One may be a typo. Look for ++ in two places near the top.
I have Feisty which has been upgraded all the way from Breezy, I think, although it may even have been upgraded from Hoary. I love this machine and I'm giving it up to a friend now. While checking everything out and preparing it, I discovered that DMA won't stay enabled for my /dev/hda. I have a /dev/hdd too, and it automagically is already DMA-enabled.

I'm reading this thread -
http://ubuntuforums.org/showthread.p...+on+hard+drive
Interestingly, following the instructions there:

me@maestro:~$ sudo hdparm -I /dev/hda |grep ‘DMA:’
Password:
me@maestro:~$

++(There's no response.) OK. So I tried the suggestion beneath, "- To view all the information about your drive run: sudo hdparm –I /dev/hda"

me@maestro:~$ sudo hdparm –I /dev/hda
–I: No such file or directory
me@maestro:~$

++OK, maybe use a hyphen instead of a dash. . .

me@maestro:~$ sudo hdparm -I /dev/hda

/dev/hda:

ATA device, with non-removable media
        Model Number:       WDC WD400BB-53AUA1                      
        Serial Number:      WD-WMA6R2202166
        Firmware Revision:  18.20D18
Standards:
        Supported: 5 4 3 
        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:   78165360
        device size with M = 1024*1024:       38166 MBytes
        device size with M = 1000*1000:       40020 MBytes (40 GB)
Capabilities:
        LBA, IORDY(can be disabled)
        bytes avail on r/w long: 40
        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 *  
             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:
                SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    DOWNLOAD_MICROCODE
                SET_MAX security extension
                Automatic Acoustic Management feature set
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
        Integrity word not set (found 0xa53e, expected 0x100a5)
me@maestro:~$

OK yes it is a Western Digital Caviar drive. The post says setting multiple sector count can slow them down.
-Also What is a "Integrity word not set (found 0xa53e, expected 0x100a5)"
And according to the post, the star by udma5 means we can use udma5.

Now here is the funny part. here we go, set DMA on from CLI:

me@maestro:~$ sudo hdparm -d1 /dev/hda

/dev/hda:
 setting using_dma to 1 (on)
 using_dma    =  1 (on)
me@maestro:~$

And it works. Disk access is about ten times as fast as before issuing the command.
So, still following http://ubuntuforums.org/showthread.p...+on+hard+drive ,
I try to set it to stay on after booting by editing /etc/hdparm.conf and adding

/dev/hda {
        dma = on
        }

Since I have no scsi or sata drives, I can't use the other options. Anyway DMA continues to REFUSE to be enabled upon reboot . . .
Until I enable it by hand again as I described above.
Any thoughts?

Current output of hdparm before hand-enabling DMA [after enabling, DMA is listed as 1 (on)]:

me@maestro:~$ hdparm /dev/hda

/dev/hda:
 multcount    =  0 (off)
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 65535/16/63, sectors = 78165360, start = 0
me@maestro:~$ hdparm /dev/hdd

/dev/hdd:
 multcount    =  0 (off)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 30401/255/63, sectors = 488397168, start = 0
me@maestro:~$

I thought of making a script to run the enabling command after boot, but I thought that's what /etc/hdparm is . . .
I don't want to make my friend type something every time he wants to move files to his flash drive . . .
( I want regular old ascii smilies for Christmas, along with WORLD PEACE - whatever . . .)

[Terry of Astoria]

Sorry. I just wanted to change the subject line. See the previous post from me.

[BlackPhoenixx]

I will look into it.

[cor2y]

i have been struggling for months to determine why ubuntu Feisty was running soooo slow for me, when doing disk intensive things like burning a cd or extracing files from the gz or zip archives, running multiple disk intensive programs .
The really large file extractions or cd burns would take in excess of 1hr, i tried copying an audio cd via both gnome baker and k3b and it took 1hr and 20 mins, even ripping a cd to disk was just as long.
Everything from updating the kernel to Gutsy (which did work)
to disabling apic and lspic in the kernel on boot all seemed to work for a little while then strangely it would stop working and i'd be back in the same boat again.
It was driving me crazy.
Just tried the guide here and once more everything is working as it should.
Also listing my disk settings via hdparm showed that dma was NOT enabled which could be the source of the problem so now its hardwired to use dma on boot via the hdparm file.
Lets hope it sticks and works.
Thank you for the guide.

[Fed]

So I'm wondering, does anyone know how to change settings like the multi sector for example, for IDE drives that are now showing up as /dev/sd* devices? For example for me:
hdparm -I /dev/sdf
shows
R/W multiple sector transfer: Max = 16 Current = 0
However, it seems hdparm can't do anything to the drives that use the scsi driver:
/dev/sdf:
setting multcount to 16
HDIO_SET_MULTCOUNT failed: Inappropriate ioctl for device
HDIO_GET_MULTCOUNT failed: Inappropriate ioctl for device

Any tips in this situation?