Speeding up Linux Using hdparm


Recommended Posts

Speeding up Linux Using hdparm
by Rob Flickenger
06/29/2000 
Are you running an Intel Linux system with at least one (E)IDE hard drive?

Wouldn't it be neat if there were a magical command to instantly double the I/O performance of your disks? Or, in some cases, show 6 to 10 times your existing throughput?

Did you ever just wonder how to tell what kind of performance you're getting on your "tricked-out" Linux box?

Don't overlook hdparm(8). If you've never heard of it, don't worry. Most people I've talked to haven't either. But if you're running an IDE/Linux system (as many folks are,) you'll wonder how you ever got this far without it. I know I did.

What's the big deal?
So, you've got your brand-new UltraATA/66 EIDE drive with a screaming brand-new controller chipset that supports multiple PIO modes and DMA and the leather seat option and extra chrome... But is your system actually taking advantage of these snazzy features? The hdparm(8) command will not only tell you how your drives are performing, but will let you tweak them out to your heart's content.

Now before you get too excited, it is worth pointing out that under some circumstances, these commands CAN CAUSE UNEXPECTED DATA CORRUPTION! Use them at your own risk! At the very least, back up your box and bring it down to single-user mode before proceeding.

With the usual disclaimer out of the way, I'd like to point out that if you are using current hardware (i.e. your drive AND controller AND motherboard were manufactured in the last two or three years), you are at considerably lower risk. I've used these commands on several boxes with various hardware configurations, and the worst I've seen happen is the occasional hang, with no data problems on reboot. And no matter how much you might whine at me and the world in general for your personal misfortune, we all know who is ultimately responsible for the well-being of YOUR box: YOU ARE. Caveat Fair Reader.

Now, then. If I haven't scared you away yet, try this (as root, preferably in single-user mode):

hdparm -Tt /dev/hda
You'll see something like:

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.34 seconds =95.52 MB/sec
 Timing buffered disk reads:  64 MB in 17.86 seconds = 3.58 MB/sec
What does this tell us? The -T means to test the cache system (i.e., the memory, CPU, and buffer cache). The -t means to report stats on the disk in question, reading data not in the cache. The two together, run a couple of times in a row in single-user mode, will give you an idea of the performance of your disk I/O system. (These are actual numbers from a PII/350 / 128M Ram / newish EIDE HD; your numbers will vary.)

But even with varying numbers, 3.58 MB/sec is PATHETIC for the above hardware. I thought the ad for the HD said something about 66MB per second!!?!? What gives?

Well, let's find out more about how Linux is addressing your drive:

hdparm /dev/hda

/dev/hda:
 multcount    =  0 (off)
 I/O support  =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 1870/255/63, sectors = 30043440, start = 0
These are the defaults. Nice, safe, but not necessarily optimal. What's all this about 16-bit mode? I thought that went out with the 386! And why are most of the other options turned off?

Well, it's generally considered a good idea for any self-respecting distribution to install itself in the kewlest, slickest, but SAFEST way it possibly can. The above settings are virtually guaranteed to work on any hardware you might throw at it. But since we know we're throwing something more than a dusty, 8-year-old, 16-bit multi-IO card at it, let's talk about the interesting options:

multcount: Short for multiple sector count. This controls how many sectors are fetched from the disk in a single I/O interrupt. Almost all modern IDE drives support this. The man page claims: 


When this feature is enabled, it typically reduces operating system overhead for disk I/O by 30-50%. On many systems, it also provides increased data throughput of anywhere from 5% to 50%.
I/O support: This is a big one. This flag controls how data is passed from the PCI bus to the controller. Almost all modern controller chipsets support mode 3, or 32-bit mode w/sync. Some even support 32-bit async. Turning this on will almost certainly double your throughput (see below.) 


unmaskirq: Turning this on will allow Linux to unmask other interrupts while processing a disk interrupt. What does that mean? It lets Linux attend to other interrupt-related tasks (i.e., network traffic) while waiting for your disk to return with the data it asked for. It should improve overall system response time, but be warned: Not all hardware configurations will be able to handle it. See the manpage. 


using_dma: DMA can be a tricky business. If you can get your controller and drive using a DMA mode, do it. But I have seen more than one machine hang while playing with this option. Again, see the manpage (and the example on the next page)! 






Turbocharged
So, since we have our system in single-user mode like a good little admin, let's try out some turbo settings:

hdparm -c3 -m16 /dev/hda

/dev/hda:
 setting 32-bit I/O support flag to 3
 setting multcount to 16
 multcount    =  16 (on)
 I/O support  =  3 (32-bit w/sync)

Great! 32-bit sounds nice. And some multi-reads might work. Let's re-run the benchmark:

hdparm -tT /dev/hda


/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.41 seconds =90.78 MB/sec
 Timing buffered disk reads:  64 MB in  9.84 seconds = 6.50 MB/sec
WOW! Almost double the disk throughput without really trying! Incredible.

But wait, there's more: We're still not unmasking interrupts, using DMA, or even a using decent PIO mode! Of course, enabling these gets riskier. (Why is it always a trade-off between freedom and security?) The man page mentions trying Multiword DMA mode2, so:

hdparm -X34 -d1 -u1 /dev/hda
...Unfortunately this seems to be unsupported on this particular box (it hung like an NT box running a Java app.) So, after rebooting it (again in single-user mode), I went with this:

hdparm -X66 -d1 -u1 -m16 -c3 /dev/hda

/dev/hda:
 setting 32-bit I/O support flag to 3
 setting multcount to 16
 setting unmaskirq to 1 (on)
 setting using_dma to 1 (on)
 setting xfermode to 66 (UltraDMA mode2)
 multcount    = 16 (on)
 I/O support  =  3 (32-bit w/sync)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
And then checked:

hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.43 seconds =89.51 MB/sec
 Timing buffered disk reads:  64 MB in  3.18 seconds =20.13 MB/sec

20.13 MB/sec. A far cry from the miniscule 3.58 we started with...

By the way, notice how we specified the -m16 and -c3 switch again? That's because it doesn't remember your hdparm settings between reboots. Be sure to add the above line to your /etc/rc.d/* scripts once you're sure the system is stable (and preferably after your fsck runs; having an extensive fs check run with your controller in a flaky mode may be a good way to generate vast quantities of entropy, but it's no way to administer a system. At least not with a straight face...)

Now, after running the benchmark a few more times, reboot in multi-user mode and fire up X. Load Netscape. And try not to fall out of your chair.

In conclusion
This is one of those interesting little tidbits that escapes many "seasoned" Linux veterans, especially since one never sees any indication that the system isn't using the most optimal settings. (Gee, all my kernel messages have looked fine....) And using hdparm isn't completely without risk, but is well worth investigating.

And it doesn't stop at performance: hdparm lets you adjust various power saving modes as well. See the hdparm(8) for the final word.

Many thanks to Mark Lord for putting together this nifty utility. If your particular distribution doesn't include hdparm (usually in /sbin or /usr/sbin), get it from the source at http://metalab.unc.edu/pub/Linux/system/hardware/

Happy hacking!

Rob Flickenger is the author of three O'Reilly books: Building Wireless Community Networks, 2nd Edition, Linux Server Hacks, and Wireless Hacks. 


--------------------------------------------------------------------------------

Discuss this article in the O'Reilly Network Linux Forum.

Return to the Linux DevCenter.



oreillynet.com Copyright ? 2003 O'Reilly & Associates, Inc.

Link to comment
https://www.neowin.net/forum/topic/137915-speeding-up-linux-using-hdparm/
Share on other sites

  • 1 year later...
  • 2 months later...

:o

Oh no. He didn't just say that, did he? :rofl:

I used to moderate here, until I found that too much of my free time was spent cleaning up, and looking for rule violations and mis-placed threads. I became obsessive-compulsive about being available to keep things in proper order.

Now I just let the staff do it (and those guys really put a LOT of effort into making Neowin a great place, I know!) and I am much happier. The kids get to see more of daddy, too, and I spend more time pitching them baseballs and such. :)

  • 4 weeks later...

Pretty cool

The correct dma modes are usually set by default either way

my hitachi eide laptop drive was missing -m16 -u1 -c3 although I didn't see any performance increase, at least I know I have it set up correctly now

both my optorite cd/dvd drives on my laptop/pc were missing -c3

I have added these settings to my /etc/rc.local (ubuntu/debian)

hdparm can't acces my SATA drive but I would guess it is optimally configured by default

It also might be worth settings -A1 (enable drive lookahead feature) and -W1 (enable write caching feature) on the HDD

Edited by Z3r0

thanks for that information daPhoenix, I downloaded sdparm via apt

sdparm is for scsi drives and works with the sata drives too

lots of information via sdparm --enquire --all /dev/sda and sdparm --all /dev/sda to see valid options

try this too sdparm --enumerate --page ca to see the caching options page, sdparm --page=ca to see the value of WCE if WCE=1 then write caching is enabled

can't see much else to play with though

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • FWIW StatCounter has been trash for over 25+ years! Back in the day (circa 2000 and GeoCities pre-Blogger era), it was useful to paste a number on your webpage indicating how many visitors you had. In the ensuing 25+ years, they've grown in reputation and changed their ways... but their overall consumer value has remained abysmal. Serious marketing agencies only cite StatCounter when there's literally no other sources available to support any marketing claims! They are the absolute lowest threshold serious companies use to push any sort of narrative about this-or-that happening. Besides their credibility being what it is, they are forever subject to quality issues. They're so bad that my DNS-level ad-filter prevents me from even viewing their main website! HA!
    • Microsoft had to shut down 70+ GitHub repos after getting hacked, brings back some by Aditya Tiwari The self-replicating malware campaign known as Miasma took the open-source world by storm. It was reported that almost 73 Microsoft GitHub repositories were infected by the worm and had to be temporarily shut down to determine how attackers compromised projects and stuffed password-stealing malware in the code. These GitHub repos span across different organizations, including Microsoft Azure, Azure-Samples, Microsoft, and MicrosoftDocs. The malware enabled attackers to steal passwords and credentials when compromised tools were opened in popular AI coding apps, including Claude Code, Gemini CLI, VS Code, and Cursor. The security firm Cloudsmith, malware analysis site OpenSourceMalware, and 404 Media were among the first to report the hack. For background, Miasma is a variant of the Mini Shai-Hulud worm, open-sourced by the threat group TeamPCP. It started its journey by compromising a Red Hat employee's GitHub account to attack the @redhat-cloud-services npm namespace. Earlier this month, Microsoft Threat Intelligence reported that the Miasma attackers published 32 malicious packages across more than 90 versions under the @redhat-cloud-services npm scope to steal cloud credentials. The worm didn't take long to start attacking source repos directly rather than package registries. It is known to skip the npm registry entirely for several targets and plant malicious code straight into public repos like "icflorescu/mantine-datatable." The delivery approach was designed to weaponize AI coding tools. Miasma's malicious payload embedded into projects can trigger automatic code execution when the infected repo is opened in an AI coding tool or IDE. The list of affected projects includes "durabletask", a Python package compromised by TeamPCP a month earlier to deliver an information stealer designed for Linux systems. That said, Microsoft has begun restoring some repos affected by the malware campaign, The Hacker News reports. A company spokesperson stated the following: Microsoft will continue to investigate the attack. It has notified a small number of customers who may have removed their content from the affected repos. The company will reach out to customers again through established support channels "if anything further is identified that requires customer action."
    • Why is Opera doing this notification at all? They have their own extension store. They don't have to obey anything dictated by Google. Others like Brave and Vivaldi that rely on Chrome's extension store, not so much. Firefox is entirely separate as well with its own extensions store. I honestly don't understand why entire world is just insisting on Chrome. Like, why? It's a stupid fat browser with barely any functionality. But sure, it's installed on everything by default. I don't understand how people even use web that's filled with tracking garbage and ads all over the place.
  • Recent Achievements

    • Week One Done
      rubentuben8 earned a badge
      Week One Done
    • Week One Done
      ARaclen earned a badge
      Week One Done
    • One Year In
      jojodbn earned a badge
      One Year In
    • One Month Later
      jojodbn earned a badge
      One Month Later
    • Week One Done
      jojodbn earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      529
    2. 2
      PsYcHoKiLLa
      231
    3. 3
      +Edouard
      131
    4. 4
      ATLien_0
      88
    5. 5
      Steven P.
      82
  • Tell a friend

    Love Neowin? Tell a friend!