ondemand cpufreq governor reacts too slowly

[Martin Emrich]

I am running current intrepid amd64. CPU is an Athlon X2 4050e on a Gigabyte GA-MA780GM-S2H mainboard.

I noticed that when I switch to the performance governor, most applications (e.g. Firefox, Opera) react much snappier than with the ondemand goveror. It seems like ondemand needs too much time to react to the increased demand for CPU power.

On my laptop (intrepid/jaunty i386, Intel Pentium M 1,7GHz on intel 855PM chipset, ondemand governor), I don't have this problem.

uname -a: Linux daisy-mae 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux
/proc/version_signature: Ubuntu 2.6.27-9.19-generic

[Antti S. Lankila (alankila)]

As a workaround, I have these lines in my rc.local to fix my two cores:

echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
echo 30 > /sys/devices/system/cpu/cpu1/cpufreq/ondemand/up_threshold

The default value of 95 seems tad high. I think it takes about 2 seconds here before CPU speed ramps up from idle, which is very irritating to watch. The lower the value, the faster it seems to react...

As a general rule, there should be a decent application-specific way to opt out of ondemand (while the application is running, it's forbidden to conserve CPU). I have some latency-critical applications that do not react well to the cpu scaler changing the cpu speed underneath them. The application's structure is a fixed length of computation that produces audio in the end. The timing of the calculation is carefully tuned with nanosleep to stop right before audio driver is ready to accept more data to minimize latency. Since the fixed period of computation takes variable time with ondemand jiggling the CPU frequency, it produces audio underruns.

[Martin Emrich (emme)]

After a recent reinstall of my laptop (got a new HDD and wanted to start fresh), this affects my laptop, too. After applying the lower up_threshold, especially scrolling in the web browser feels much snappier.

To keep it permanent, I just added the line to my /etc/rc.local.

As a refinement, one could even move it to acpi, and set different values whether on battery or AC.

[Rocko (rockorequin)]

I'm experiencing something like this bug, but only after the computer has been running for a while. It's most noticeable playing games under wine: after rebooting I get a good frame rate, whereas after the computer has been on for some hours if I play the same game I have to set the CPUs to performance instead of ondemand, or my framerate is halved. Rebooting always fixes the problem. I find it with every kernel since Intrepid, including the latest 2.6.30.rc7.

[Martin Emrich (emme)]

Since upgrading to jaunty, the entry in /etc/rc.local no longer works, as the CPU is on "performance" during startup (thus the sysfs files for ondemand are not there).

Is there another way to make the fix permanent?

[Rocko (rockorequin)]

Jaunty has a startup script called /etc/init.d/ondemand which sleeps for 60 seconds to allow login and then tries to set the governor to ondemand (that explains why sometimes my Jaunty boots up in performance mode, not ondemand mode). You could try adding the 'echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold' in there. I noticed that if you set one up_threshold, the other CPU's up_threshold also changes so you probably don't need to do CPU1 as well.

Bug #107545 is the opposite of this bug! It seems that Ubuntu used to use a much lower value of 31 but then changed it to 95 (why? I read the default is supposed to be 80).

It still doesn't explain why I get good performance after rebooting but it then degrades with time. Perhaps the ondemand governor's sampling rate drops with time.

[Rocko (rockorequin)]

Just confirming that modifying /etc/init.d/ondemand works for me (this sets both CPUs' up threshold to 40):

  echo -n ondemand > $CPUFREQ
  # set a more aggressive upscale factor. This should set both cpu0 and cpu1
  echo -n 40 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold

or if you prefer to do each CPU separately, you could add this after the CPU_FREQ for loop:

 for CPU_THRESHOLD in /sys/devices/system/cpu/cpu*/cpufreq/ondemand/up_threshold
 do
  [ -f $CPU_THRESHOLD ] || continue
  echo -n 40 > $CPU_THRESHOLD
 done

Incidentally, I think that this script should probably keep running until it detects that the necessary files exist rather than just trying once after 60 seconds.

[captaintrav (captaintrav)]

I have noticed this as well, but mostly when watching video content that stresses the CPU more at certain points, when there is a lot of movement. Totem starts having to drop frames, by the time the CPU frequency increases, the need for more performance has often passed. I am running jaunty amd64 on an AMD X2 4850e (desktop system). I have been switching to the "performance" governor when watching videos to mitigate the issue, but will try the suggest changes here to /etc/init.d/ondemand

[captaintrav (captaintrav)]

I have another X2 running Hardy LTS (i386) and haven't noticed this behavior before with cpu frequency scaling.. for reference, /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold on the system that always just worked was a paltry 31. This issue probably explains why a somewhat slower system running hardy(dual 2.0ghz) feels faster than the newer 4850e (2.5ghz dual) system running jaunty.

[George Roberts (g-roberts0)]

I was looking to post a bug report about the ondemand governor, but this one looks similar enough [see what you guys think, I'll open a new report if it's too different].
My problem is similar, except it's not that the governor reacts too slowly, more that it doesn't give enough Hz when doing something which clearly benefits when the speed is set higher. I can start watching a HQ youtube video while it's set to ondemand and the gov stays at the lowest level, the video will appear a little slow and stuttery at this point. I can then set it to performance mode, and the video is perfectly fine. If I then set it to ondemand again while the video is still running, the level switches to 2nd from lowest instead! And that level works fine too. If only the ondemand governor would switch up automatically to whatever level is needed!

This isn't the same as the bug I've seen where the governor won't change at all though, if a process comes along that clearly uses alot of cpu, then the ondemand gov kicks it up to full.

[Zeno (zeno-endemann)]

I had the same issue before Karmic. In Jaunty the sampling-rate (on AMD 5050e) defaulted to 1040000 which gave bad responsiveness, such as stuttering flash-videos. With Karmic the default here is 109000 and Flash seems to run fine now, so this bug might be fixed. The up_threshold is still 95 though.

[mc (mcclement-gmail)]

I also have this issue. Since the ondemand up_threshold is set default at 80, browsing is somewhat less responsive compared to using performance governor. I fixed this by modifying the /etc/init.d/ondemand to set the up_threshold to 20. However, this is not a permanent fix. When I switch power profiles, up_threshold value goes back to 80 when I revert to ondemand governor. Is the 80 value built into the kernel or is there a conf file we can modify to change this value permanently?

I noticed that a lot of users have different preferences with regards to the up_threshold value. Some would want the value up high and some like me want the value low. Would it be possible to have a conf file which contains the up_threshold value and could be modified by users according to their preferences? I think this would be helpful to all.

Karmic System
AMD Turion TL-64 (2.2GHz)
4GB Ram

>uname -a
Linux dv2845se 2.6.31-16-generic-pae #53-Ubuntu SMP Tue Dec 8 05:20:21 UTC 2009 i686 GNU/Linux

[2hot6ft2 (hot6ft2)]

I am also affected by this. CPU's slow to respond to increased demand while in On Demand mode set by Frequency Scaling applet. Resulting in applications greying out for a few moments.

I am going to try the fix posted by Rocko
*********
Modifying /etc/init.d/ondemand (this sets both CPUs' up threshold to 40):

  echo -n ondemand > $CPUFREQ
  # set a more aggressive upscale factor. This should set both cpu0 and cpu1
  echo -n 40 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
*********
Ubuntu Karmic 9.10
AMD Turion X2 64
32 bit OS
3 GB RAM

uname -a
Linux UUE-2-laptop 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 i686 GNU/Linux

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Oliver Joos (oliver-joos)]

Please reopen this bug. According to the upstream report on kernel.org it is still an issue with 2.6.37 and probably 2.6.38.

A workaround is mentioned there: set .../cpufreq/ondemand/sampling_rate to sampling_rate_min

[Oliver Joos (oliver-joos)]

Bump?

I'd prefer to continue here instead of opening a new report as the automated scripts wrote. Please set this bug to "Confirmed" or confirm that a new page is really what is intended in this case.