[Solved] Hard drive stuttering

meph · 2011-06-16 15:27:50

Hey everyone,

A few days back I posted a thread about strange lags I've been experiencing. At first I thought the problem was solved, but after some more testing I found out that I have been wrong in my basic assumptions and have to start all over again.
Here is a link to the original thread for refference.

How does the problem manifest itself:
On my laptop I experience seemingly random lags during everything I do. For example, autocompletion of file names often takes like 3 seconds. Mplayer chokes while playing a movie, both video and sound stop instantly and after a few seconds it continues to run flawlessly, at least until next lag. After hitting the "X" to close some application, for example firefox, it takes a few seconds before anything at all happens. The same happens when launching any app, even lightweight applications that usually start up almost instantly. Sometimes even "su" takes a few seconds before it asks for password.
When the lag occurs the desktop environment/WM (tried gnome, kde and fluxbox) remains otherwise responsive. At least mouse cursor doesn't hiccup at all, it's hard to try anything else since the lags are only about 3 seconds long.
The problem is sort of intermittent - if I repeat the same action over and over again it doesn't happen every time, but it's really disturbing.

What I know so far:

it's not X server related. The same happens with X shut down.
it's probably irrelevant, but direct rendering works and it doesn't matter whether I use compositing or not.
during the lag CPU activity doesn't spike up.
iotop doesn't show anything weird either
hard drive indicator light is lit up during the lag, so I assume it's doing something (it's way too quiet to be able to hear whether it's actually working)
the commit option in fstab doesn't help

That's about it...

Likely suspect?
I tried to watch the kde system monitor while playing a movie in mplayer. During the lag none of the gauges spiked up, but I noticed an interesting thing. The value for mplayer in the CPU usage column changed to "disk sleep" everytime for the duration of the lag. And as I think about it, it really seems to affect only things that require any immediate hard drive access. For example, in kde even with compositing and all that fluff on I can move windows all day long and nothing happens, but then opening a simple text file with nano lags. Is it possible that the hard drive spins down for some reason and then takes those few seconds to start up again? If so, then why?

Laptop specs
ACER Extensa 5235
Intel Celeron Mobile T3500 2,1 GHz
Intel GL40 Express
4 GB DDR3
500 GB 5400 RPM SATA HDD
Intel Graphics Media Accelerator 4500M
= low end laptop, but should be more than enough

I'll be grateful for any input. It drives me insane already, I'm not yet any closer to resolving this, and it makes the laptop almost unusable...

Thanks

P.S. for mods: I'm not really sure whether it's a laptop issue or general hardware issue, so I posted here. Please move the thread if you feel it's appropriate.

Last edited by meph (2011-06-17 22:56:21)

ewaller · 2011-06-16 15:36:31

It is possible the drive is spinning down. You might try hdparm -B 254 /dev/sda (Change sda as appropriate, of course.)
Also, I would take a look through your logs to make sure you are not seeing any drive errors.
Does your drive support S.M.A.R.T? If so, I recommend loading up one of the many utilities and check the drive's built in test results.

Edit: Here is fine for now. Desktops can spin their drives down too

Last edited by ewaller (2011-06-16 15:37:55)

meph · 2011-06-16 15:46:45

Will try and see what happens. After that I'll post here some results, but it will take me some time to test it, don't want to prematurely jump to conclusions like I already did once before

And ok better ask than... well, you know cheers for quick answer anyway

to be continued

meph · 2011-06-17 22:55:41

Marking as solved, though I'm a bit pesimistic, can't believe the solution could be so simple Setting APM to a more aggresive value using hdparm did the trick. One more question though, I've seen some advices to make the change permanent using rc.local. But even without doing that it seems that the change remained active after reboot. So how is it?

In any case, thanks for your help

ewaller · 2011-06-17 23:24:45

The working value is stored in the drive and is loaded at power up, or by command. It might survive a reboot,but how about a power cycle?

meph · 2011-06-17 23:44:32

Correct again. Reboot is fine, but the new value didn't survive unplugging power cord & removing battery. I rarely take the battery out and even after its capacity goes south I guess it should provide enough power to keep the value stored. But since there are no real downsides to it, I guess I'll have it set up every boot anyway.

Thanks for your help again and again, you've been very helpful

Arch Linux

#1 2011-06-16 15:27:50

[Solved] Hard drive stuttering

#2 2011-06-16 15:36:31

Re: [Solved] Hard drive stuttering

#3 2011-06-16 15:46:45

Re: [Solved] Hard drive stuttering

#4 2011-06-17 22:55:41

Re: [Solved] Hard drive stuttering

#5 2011-06-17 23:24:45

Re: [Solved] Hard drive stuttering

#6 2011-06-17 23:44:32

Re: [Solved] Hard drive stuttering

Board footer