linux cpu throttling fix isn't persistent - why?

If you're using Ubuntu you also need to disable the"ondemand" daemon:

sudo update-rc.d ondemand disable

See here for more details: http://askubuntu.com/questions/523640/h...erformance

Instead of using the "performance" setting I set the frequency explicitly and that works for me very well - even if I don't use max non-overclock frequency. Seems like fixed frequency setting works best (even if it's a relatively slow frequency) because the throttling up/down causes momentary interruptions to real-time audio processing (on my hardware it does anyway).

Here is the shell script I use for going flat out on all cores:

#!/bin/bash

MAX_FREQ=$(cpufreq-info | grep limits | head -n1 | cut -f2 -d- | sed 's/ //g')
ICPU_MAX=$(cpufreq-info | grep analyz | tail -n1 | cut -f 3 -d' ' | cut -f1 -d:)

for ((i = 0; i <= $ICPU_MAX; i++)); do
        sudo cpufreq-set -c $i -f $MAX_FREQ
done

...which translated into more human readable lingo does the following:

1) Use the cpufreq-info command to find out what fixed frequencies are supported
2) Use the cpufreq-set command with the -c and -f options to set a fixed frequency for each core

Thankjs spfenwick, the link is very helpful. I'm running Mint, which is derived from Ubuntu if you reach back far enough, and the utilities mentioned are in place. Seems like ondemand is key; I will definitely look into this.

Thanks SteveLy, the script is very helpful. I'll look into it if all the previous approaches fail - can't do everything at once.

Hmm. Followed steps - /etc/default/cpufrequtils, disabled ondemand, restarted cpufrequtils - and cpufreq-info still shows I'm running at the base frequency (1.60 GHz). However my governor script reports I'm using the performance governor. Not certain if that's accurate as I'm using a different approach to set the governor.

Might move on to SteveLy's approach to explicitly set the max frequency for each core (2.70 GHz), though I'm a little concerned about running maxed out 24/7.

My thought is not to use my script without checking out what it does on your system (I'll describe how to do that safely below). On my Linux Mint 17.2 on a Dell D620 it runs the cores at max non-turbo no-over-clocking frequency. When I said "going flat out" I meant without overclocking, which I am not a fan of in general. On my laptop running CPUs at max normal speed does not cause any issues (there is no excessive heat or CPU fan activity).

To see if my script would work in the way I intended it to on your machine (i.e., with no overclocking), run this first in a terminal:

cpufreq-info | grep limits | head -n1 | cut -f2 -d- | sed 's/ //g'

For me this outputs the string "1.80GHz", which is the highest non-overclocked frequency I have available. See what you get and if you're happy with that CPU clock speed. Then run this:

cpufreq-info | grep analyz | tail -n1 | cut -f 3 -d' ' | cut -f1 -d:

which should output an integer that is one less than the number of (virtual) cores, i.e., 3, if you have a CPU capable of 4 threads. (I believe I have two physical cores and 4 virtual CPUs, just like your NUC I suspect, so that's the result I get.)

If all that checks out my script should work for you. But it sounds like other posters might have better ideas worth exploring.

I had done that earlier in order to find the maximum frequency, outputs "2.70GHz".

Yep, it outputs 3, I have 4 cores.

Unfortunately your script doesn't work on my setup (even when I run as root) and I suppose never will because of the cpufreq-set command called out by groovy:

Error setting new values. Common errors:
- Do you have proper administration rights? (super-user?)
- Is the governor you requested available and modprobed?
- Trying to set an invalid policy?
- Trying to set a specific frequency, but userspace governor is not available,
   for example because of hardware which cannot be set to a specific frequency
   or because the userspace governor isn't loaded?

If I'm putting together properly what groovy has said, then the script I first posted (which sets scaling_governor) should work. Which it does, if I can believe its output. The problem is, it's not sticky. Or it wasn't. I'm beginning to think disabling the ondemand daemon per spfenwick did the trick. So far I'm in performance mode and it seems to be sticking.

BTW cpufreq-info is still telling me I'm on base frequency, but since that command goes with cpufreq-set, I'm thinking I shouldn't believe it.

nuc5 mark # cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 0.97 ms.
  hardware limits: 500 MHz - 2.70 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 500 MHz and 2.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
analyzing CPU 1:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 0.97 ms.
  hardware limits: 500 MHz - 2.70 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 500 MHz and 2.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
analyzing CPU 2:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 0.97 ms.
  hardware limits: 500 MHz - 2.70 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 500 MHz and 2.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
analyzing CPU 3:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 0.97 ms.
  hardware limits: 500 MHz - 2.70 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 500 MHz and 2.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
nuc5 mark # 

Thanks,
Mark

I'm using Linux Mint 17.3, Cinnamon edition

I have had the same problem: not being able to control the CPU frequencies, which (until I found a solution) always seemed to fall back to a lower than specification clock frequency. Here is what I have learned so far (as faulty as my learning or understanding may be; if someone more technically-minded notices a mistake, please correct any misinformation I'm about to provide).

CPU frequencies used to be set or controlled by various programs or utilities which relied on interaction with the ACPI interface standard between software and hardware. But newer Intel CPUs, including the multicore CPUs, use an internal monitoring and CPU-frequency-scaling method called intel_pstate.

Since linux kernel 3.9 (I currently use a 4.2 low-latency kernel), an intel-pstate driver has been included in the kernel (not necessarily as a loadable/unloadable module, but directly within the kernel itself), and when launching linux (when the computer boots) if it notices that the CPU in one's computer is one of the newer CPUs with intel_pstate, that functionality supersedes and replaces any older ACPI approach to setting or controlling CPU frequencies, causing all those user-operated CPU frequency setting programs or utilites to fail or cease to have any effect.

The solution I'm currently using, suggested by various linux users on the Internet, is to disable the kernel intel_pstate driver at boot time, by editing the GRUB bootloader configuration file (/etc/defalt/grub) as the root user or using sudo, to change the line reading--

GRUB_CMDLINE_LINUX_DEFAULT=

--to--

GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=disable"

Then it is necessary to run (as root or using sudo) the command update-grub, so that your changes to /etc/default/grub will be written to the files in the /boot directory. Then, upon rebooting the computer, the intel_pstate CPU monitor/governor driver should be disabled and the CPUs (all of the cores) should run at the manufacturer specified clock-frequency.

On my system, in addition to adding intel_pstate=disable to the kernel commandline, I added threadirqs to that commandline--

GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=disable threadirqs"

--based on some recommendations or comments I found on the Internet, although I'm not sure if that helps or not. I also installed the rtirq package, which (once configured) gives a higher priority (in terms of interacting with the CPU) to the IRQs (interrupt requests used by the computer motherboard and CPU) assigned to one's soundcard.

I hope this information helps and is not misleading. Someone please correct the information if an error is found.

Thanks for the very informative post, Stephen.

I think I've got performance mode working now thanks to all the help I've gotten on this thread. Not sure your approach of essentially disabling new technology in order to use old technology is really the best way to go. Unless there's something I'm missing of course .. maybe there's some advantage to the old way I don't see? Have you concluded that performance governor with intel_pstate isn't really forcing max frequency?

Clearly my script is not suited to your system. I did not create it with any knowledge about other systems; I just looked to automate what I was doing manually previously.

Just try cpufreq-set manually, e.g.:

sudo cpufreq-set -c 0 -f 1.60GHz
sudo cpufreq-set -c 1 -f 1.60GHz
...

or more succinctly:

for i in 0 1 2 3; do sudo cpufreq-set -c $i -f 1.60GHz; done

and see if that works. I suspect 2.70 GHz is overclocking your system, since your lower limit is only at 500 MHz. For me the lower limit is 1.0 GHz, upper is 1.8 GHz and the latter is what the "performance" setting also yields. In your case I'd just go with 1.6 GHz fixed frequency and see how that goes.

I suspect (but I don't know) that anything (much) faster than that can only be maintained for short bursts and that's why you see the system running at 1.60 GHz in "performance" mode. Like I mentioned before, the frequency switching/throttling seems to intrude on real-time audio when it happens, so perhaps at a fixed 1.60 GHz (or whatever your CPU can maintain indefinitely) you will get better real-time audio performance than by letting the system briefly go up to "turbo" speeds when it feels like it.

I am just guessing though. I'm not familiar with Intel NUC or any other relatively recent hardware. Sounds like groovy may be a lot more knowledgeable about such things.

I'm glad to hear, thanks for your feedback!

Btw, the "performance" scaling_governor of intel_pstate even makes use of the Burst Frequency modes of a CPU if you compare my powertop output to the specs of the N2930:

Processor Base Frequency    1.83 GHz
Burst Frequency            2.16 GHz

I wasn't clear on why that was (other than maybe specifying a higher fixed frequency than the system can handle), since you started the thread stating that you were using cpufreq-set to begin with.

Glad you found a good solution in any case. I'll bookmark this thread for future reference in case I need to tinker with different computers in the future.

You're right, this works:

sudo cpufreq-set -c 0 -g performance

but this fails:

sudo cpufreq-set -c 0 -f 1.60GHz

The error messages cover a lot of possibilities, including trying to set a specific frequency, which I think is key on my system. I abandoned digging further once groovy pointed out this technique doesn't work with intel_pstate anyway.

Glad to know this thread might be helpful to others - that's always in mind.