CPU Scaling too aggressive

[John Moser]

CPU frequency scaling seems to be overly aggressive. On my 1.9GHz Athlon Brisbane X2 65nm machine, I've got quite a bit of power... playing an MP3 puts me at 22% for one CPU core (sampled over 3 second) and pushes me immediately from 1GHz up to 1.9GHz.

The default sampling rate (1.24 seconds) is fine; I sampled over 1 second and got 36% CPU usage (out of 200%; I have 2 cores), 684MHz. 1.0GHz mode should handle this fine but the CPU scales up.

The default threshold turned out to be 31% (of one CPU/core, not of the whole set; this makes sense because not all CPU-demanding apps are multi-threaded). As soon as I hit 31% of the CURRENTLY SCALED CPU over 1.24 seconds, I got thrown into the next CPU frequency (1.9GHz; very coarse grained here). Note this is relatively measured from the current scaling mode; so my 36% CPU usage was measured as 68.4% of a 1.0GHz CPU.

To correct this, I set the up_threshold to 95% and installed sysfsutils to make the changes persist. My /etc/sysfs.conf looks as below:

devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold = 95
devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate = 620000

The first line is default; the second line is relevant change; the third is a reduced sampling rate I added to improve frequency scaling response under load, which also causes small, momentary spikes to throw the threshold up higher.

I recommend implementing a higher up_threshold, perhaps 70-80%. Reducing the sampling rate may also prove interesting; I am having good results with 95% threshold and 620mS sampling rate. My CPU stays in 1.0GHz mode until I need out; it switches out quickly; and under load from something as simple as Nexuiz it stays in 1.9GHz mode to meet CPU demands. Anything under 50% CPU load sampled every half second seems to keep me in low-frequency mode, excellent for laptops.

[Brian Murray (brian-murray)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in recently. We were wondering if this is still and issue for you? Thanks in advance.

[John Moser (nigelenki)]

bluefox@iceslab:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
31

Yes it's still an issue. My laptop stays at 1.6 or 2.0GHz just because I'm typing in Firefox or someone sent me a gmail message and the title in the tab is flashing. Setting the above keeps me low, except when aggressively switching desktops (causing a lot of screen redraws) or encoding something or doing something else that actually pushes the CPU.

[Oliver Joos (oliver-joos)]

I can confirm this issue!

On my Laptop totem or xine use approx. 60% of 800MHz. By default up_threshold is 31, so the CPU goes up to 2GHz, which makes the fan spin quite loud.

The only work-around is to setup a cronjob for root that changes up_threshold to 90 every 15 mins - not very nice. But I did not find all the scripts that reset up_threshold to 31 again and again. (I still use Ubuntu 7.04 Feisty)

[Leann Ogasawara (leannogasawara)]

Would it be possible for you to test the Hardy Heron 8.04 Alpha series which is currently under development and contains an updated version of the kernel: http://www.ubuntu.com/testing . Thanks.

[Oliver Joos (oliver-joos)]

I tested it with a fully updated Hardy Heron 8.04 Alpha: up_threshold is still 31

> uname -a
Linux oliverhp 2.6.24-11-generic #1 SMP Fri Feb 29 22:08:31 UTC 2008 i686 GNU/Linux

The bad thing is, that the default of 31 is not only set at boot time. It is set again upon standby&resume, hibernate&resume, even logout&login and perhaps more occasions.

A nice solution would be, that .../cpufreq/ondemand/up_threshold would not only change the current value but also the default which now seems to be built in the kernel. This way a script at boot time or an entry in /etc/sysfs.conf could set a value that will not change until the next reboot.

[Daniel Bonniot de Ruisselet (bonniot-users)]

In Gutsy, I find that setting up_threshold in sysfs.conf does not have effect after boot (I need to call /etc/init.d/sysfs restart manually).

[cbsim (cbsim)]

I can confirm this too, in the newly installed Final Ubuntu 8.04, just running Deluge BitTorrent Client alone will trigger it to maximum.

[cbsim (cbsim)]

"/sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold" is set to "11" by default in Ubuntu 8.04, although it is possible to change the value but I was unable to make it permanent.

[ski (skibrianski)]

Interesting, as I am having the opposite problem. While off of battery power, my cpu *never* goes to full throttle. I also have up_threshold at 31. amd64, hardy heron here.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Will Bickerstaff (willbickerstaff)]

This can be changed with gconf-editor under apps>gnome-power-manager-cpufreq
setting performance_ac or performance_battery to 100 gives a up_threshold of 11 setting to 0 gives up_threshold of 99
37=85,
25=90

[Tim Gardner (timg-tpi)]

Jaunty cpu_freq is defaulted to CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y

[draft (ridershome)]

I'm using an Aspire One netbook and have a really bad performance with Jaunty. The problem is that the ondemand governor does not react by increaing clock speed e.g., when watching a flash movie. The flash movie works find if I change to the performance governor, but with ondemand its unwatchable. Its similar to the problem described here: http://ubuntuforums.org/showthread.php?t=1111090. So, for me the previous release, Interpid, the scaling worked much better and it was not too aggressive.

[greg (grigorig)]

I'm also seeing bad interactivity and erratic performance on an Atom-based netbook here. This is especially evident with bursty loads, as caused by the Flash plugin when watching videos, for example.
If I remember correctly, the former default was 80%, and this seems to work a lot better than 95, without being too aggressive the other way around.

Still, going lower than this, to about 50-60%, makes scrolling in Firefox and the simple Metacity minimize animations a lot more smooth -- the frequency ramping doesn't seem to work as well as it should in theory (according to the cpufreq developers, even 100% should work fine if CPU load measurements are exact, which they should be now).

FYI, gnome-power-manager does not modify this setting anymore.

[Owen Williams (ywwg)]

I have a good, fast machine, a Dell XPS M1330 (800MHz-2.4Ghz), and I've seen this problem too with flash videos. The new default threshold is too high. I find a value of 35 or lower is needed to properly scale the CPU while playing back video.

[Oliver Joos (oliver-joos)]

@Owen and @draft:
If you can reproduce the bad performance of flash videos, please try if lowering the sampling_rate would help. Minimum is 10000 us, try 40000 us (= 25 fps):

$ sudo su
$ echo 40000 >/sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

If the peaks of CPU demand are too fast while rendering flash videos we should consider lowering the sampling_rate and not up_threshold. The sampling overhead seems pretty low meanwhile and a reasonable up_threshold can save much power.

[Owen Williams (ywwg)]

That setting doesn't seem to help much, if at all. the cpu is still mostly staying on the lowest setting and I'm still dropping frames. Right now I'm using this video as a test, because it has a lot of pans which make dropped frames more obvious: http://www.myfoxla.com/dpp/news/local/California_Ghost_Towns_20090511

I get an "Invalid Argument" error if I try to set the sampling rate lower than 40000

I can understand the power-saving issue, but I'm on AC power.

[Rocko (rockorequin)]

@Oliver: I tried setting the sampling rate to 40000 as suggested, but it stays set to 80000 (I am using kernel 2.6.30-rc7 in case that makes a difference). sampling_rate_min is set to 40000. Why alter the sampling rate instead of the up threshold, though?

[Oliver Joos (oliver-joos)]

Stange, on my working system (8.04.2, Pentium M 2GHz) the sampling_rate_min is 10000 and setting sampling_rate to this value is possible. Did you try the 2 commands "sudo su; echo ..." or only "sudo echo ..."? The first one works here.

As I understand it: lowering the sampling_rate makes the measuring of CPU load "more instant". 40000 makes a CPU load of 70% mean: during the last 40000 ms the CPU was used 70% of the time. So if a flash video decoder encounters more complex frames then the system will detect this only 40000 ms later.

You could try it with a Live-CD of Jaunty final, without changing anything in /sys. If it is still reproducible on your machine then there is a (serious) problem and you should report it here and add what CPU you have:

$ sudo lshw -C processor

Also try disabling any Desktop effects ("Compiz"). Video drivers seem under heavy development since Jaunty.

[Oliver Joos (oliver-joos)]

Sorry for the typo: 40000 means 40000 us (microseconds), not ms.

[Rocko (rockorequin)]

I can change sampling_rate to 40000 with the 2.6.28-12 kernel, but not the 2.6.30-rc7 kernel. Values equal to or above 80000 are fine.

This behaviour looks to be deliberate in 2.6.30 - cpufreq_ondemand.c has this in it:

/* Above MIN_SAMPLING_RATE will vanish with its sysfs file soon
 * Define the minimal settable sampling rate to the greater of:
 * - "HW transition latency" * 100 (same as default sampling / 10)
 * - MIN_STAT_SAMPLING_RATE
 * To avoid that userspace shoots itself.
*/
static unsigned int minimum_sampling_rate(void)
{
 return max(def_sampling_rate / 10, MIN_STAT_SAMPLING_RATE);
}

so the kernel must be calculating a minimum of 80000 for my processor (Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz). It's the same on another PC with a Pentium M @ 1.7 GHz.

The main reason I've been looking at changing from the defaults is that after rebooting, I get good performance, but after running for some hours, the system becomes reluctant to switch quickly to max freq (my test case is running a game under wine; it runs typically at 90-120% CPU as reported by top, and even with up_threshhold set to 80, the CPU mostly stays stuck at 800MHz, and the frame rates suck). I get this with the stock kernel as well as the 2.6.30 kernel.

[Oliver Joos (oliver-joos)]

Could it be that your test-app runs with a nice value above zero? You can check this with command "top" (column "NI"). If so, then you can make you cpu accelerate by executing the two commands:
$ sudo su
$ echo 0 >/sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load

I've no experience with kernel 2.6.30 yet. But a sampling_rate of 80000 should be low enough. My startup-script sets it to 60000 and everything runs jitter-free (including flash videos and wine Starcraft ;-).

[Rocko (rockorequin)]

My test-app (wine CoD4) isn't running with a nice level above zero. But perhaps there's a problem with the kernel incorrectly recognising nice levels. Shouldn't I set it to one rather than zero though? The default setting is currently zero.

[Oliver Joos (oliver-joos)]

No, nice level 0 is default for user processes. A *negative* value gives more priority to a process (see "man nice").

You were right! In Jaunty my sampling_rate_min is also 40000 (was 10000 in Hardy). But as expected, I am still able to set sampling_rate down to 40000. Nevertheless 40000 against 80000 should not make a big difference for wine or flash playback.

[Oliver Joos (oliver-joos)]

To verify if CPU scheduling is your problem you could try "cpuburn". Commands in this package are: burnP6, burnK7, ect. (optimized for different CPU types) and they just waste CPU cycles. Run your test-app with higher prio together with burnXY:

$ burnP6 &
$ sudo nice -1 wine CoD4

If your test app shows much more or less(!) jitter than when running alone, then there is a problem with CPU scheduling and/or power-saving on your system. If it does not make a big difference, then it is more likely a problem with the video driver, DMA transfers or similar.

About me: I am not a Linux kernel guru. Me too, I just saw these CPU scaling issues since Hardy. Here they were gone since Jaunty final. But I am glad to help finding the cause or solutions for systems which are still affected.

[Rocko (rockorequin)]

Thanks, Oliver. I tried this and the performance was the same running burnP6 and running it with a nice level of -1. Strangely, with up_threshold set to 40, there was never a drop in performance: as soon as I changed it back to 95, the drop in fps was immediate. Running glxgears actually increased fps in CoD4!

Then I discovered that once performance gets reduced to this level, turning off compiz restores it (normally it makes no difference). Turning compiz back on had some strange effects - after I closed CoD4, video performance dropped dramatically - I could see the screen redrawing pixel line by pixel line. Changing to a console (ctrl-alt-f1) and back fixed it. So it must be a compiz problem, not a scheduling problem.

[Oliver Joos (oliver-joos)]

Nice to hear that! If compiz and glxgears influences your frame rate and burnP6 with lower prio does not, then it is most likely a problem with 3D graphics. It's strange that changing up_threshold does make a difference. But IMHO this points to a race condition in the video driver.

In Jaunty the ATI, Intel and I think also Nvidia drivers are under heavy development. Perhaps you find a solution in a radeon/intel/nouveau bug or you could help by filing a new bug with your observations. If you do further experiments with process priorities (= nice values) then first disable "ignore_nice_load" (see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/107545/comments/22). Otherwise the results are too complicated to interpret.

[Magnes (magnesus2)]

I noticed that up_threshold on my computer was 95 (is it default) which caused HD movies to play like on slow computer. I changed it to 60 to correct the problem. Maybe 95 is to high for a default value in ondemand?

[Oliver Joos (oliver-joos)]

Please note that this bug is in state "Fix Released" and was about the opposite! Before Jaunty up_threshold was 31, which wastes power and forces loud fans while playing movies or even mp3.

Now the default is 95 which causes jitter on some systems. There is a new bug about this problem in Jaunty that can be solved by *REDUCING* up_threshold. Please file your findings and system specs there:
https://bugs.launchpad.net/bugs/326149

Meanwhile use Wills comment to reduce up_threshold permanently:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/107545/comments/11

[uschxc (uschxc)]

The cpufreq folder under apps->ghome-power-manager has been removed in Lucid. I can not change my up_threshold value from 95 which virtually never upscales any of my 8 i7 cores

[Thorbjørn Lindeijer (thorbjorn)]

Just a note for other people that read this. I had the same problem described here on Ubuntu 10.10 beta, and also thought it must be some CPU scaling problem, but like Oliver it turned out to be a GPU scaling issue (running glxgears made it go away).

I have found the easiest way to fix this is to change the Preferred Mode under PowerMizer in the NVIDIA X Server Settings to "Prefer Maximum Performance" rather than "Adaptive". I'm not sure if there is anything less rigorous, but that fixed it for me.