For computers that run Linux and have CPUs that use--

• intel_pstate functionality (rather than the older ACPI cpu-frequency method and user programs)

• a linux kernel version 3.9 or newer (which contains the intel_pstate driver in the kernel code)

This is newer version of the CPU-frequency-setting script I posted earlier. I created it for my own use, rather than completely disabling CPU frequency scaling by using the "intel_pstate=disable" argument to the command line that launches the linux kernel at boot time. The script might be useful to other Linux users also.

This version of the CPU-frequency-setting script is more versatile, can change the intel_pstate governor to either "powersave" or "performance (the only two governors intel_pstate currently allows), has some error detection, more command-line feedback as the script runs, etc. The instructions are in the comments section contained within the script (the lines beginning with a # at the top of the script).

#! /bin/sh
#
# Author: Stephen C. Doonan, stephen.doonan@gmail.com
# Version: 1.2
# Released: February 23, 2016
#
# This shell script has been tested in the bash and dash shells
# and will probably run well in most linux environments;
# please let me know at the above email address if you
# encounter problems or have comments or suggestions.
#
# This script changes intel_pstate CPU-core governors to "performance" or "powersave"
#
# The text of this script can be copied and pasted into a new plain-text file
# (using a text editor, not a word processor).
# 
# Save the script as a file called (for example) governor-intel-pstate in your home directory,
# then in a command-line terminal, in the directory, in which this script was saved,
# execute the following commands--
#
# chmod a+x governor-intel-pstate
# sudo cp governor-intel-pstate /usr/local/bin/
#
# Then you may execute the script by typing (in a command-line terminal):
# sudo governor-intel-pstate
#
# Note that it may require a short while before the command cpufreq-info shows a
# change in the CPU frequencies, after changing the governor.


GOVERNOR_TO_USE="none"


echo "\n\n"
echo "INFORMATION"
echo "-------------------------------------------------------------------"
echo "This program sets an Intel pstate CPU-frequency governor to"
echo "either \"powersave\" or \"performance\""
echo "It must be run as the root user or using the sudo command."
echo " "
echo "--> YOU ARE CURRENTLY RUNNING THE PROGRAM AS USER: $(whoami) ..."
echo "-------------------------------------------------------------------"
sleep 3

if [ ! -e "/sys/devices/system/cpu/intel_pstate" ]
then
    echo " "
    echo "Your CPU does not use intel_pstate or it has been disabled as a"
    echo "linux kernel driver or in the BIOS"
    echo " "
    exit 1
fi

if [ ! -w "/sys/devices/system/cpu/cpu0" ]
then
    echo " "
    echo "NOTE: your username, $(whoami), cannot successfully run this command." 
    echo "You must be the root user or use the sudo command to execute this script."
    echo " "
    echo "--> Will attempt to run this command again using sudo, which will"
    echo "require your administrative password (your user password)"
    echo " "
    echo "Attempting to run command using sudo; please wait a moment ..."
    echo "\n\n\n\n\n"
    sleep 5
    exec sudo "$0"
fi

echo " "
echo "Which intel_pstate CPU governor would you like to use?"
echo "1 -- powersave"
echo "2 -- performance"
echo " "
echo -n "Which governor? (Enter 1 or 2 here): "
read GOVERNOR_TO_USE

if [ $GOVERNOR_TO_USE = 1 -o $GOVERNOR_TO_USE = 2 ]
then

    case $GOVERNOR_TO_USE in
        1 ) echo "\nUSE GOVERNOR: powersave\n" ; GOVERNOR_TO_USE="powersave" ;;
        2 ) echo "\nUSE GOVERNOR: performance\n" ; GOVERNOR_TO_USE="performance" ;;
    esac
    
    sleep 1
    CPU_NUM=1
    for GOVERNOR in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    do
        echo "Changing governor for CPU" $CPU_NUM "to" $GOVERNOR_TO_USE
        echo -n "$GOVERNOR_TO_USE" > $GOVERNOR
        CPU_NUM=$((CPU_NUM+1))
    done
    echo " "
    echo "DONE: Governor changed to $GOVERNOR_TO_USE for each CPU"
    echo " "
    sleep 1
    echo "--> Note that there may be a slight delay before the"
    echo "governor begins to affect the frequencies of each CPU"
    echo " "

else
    echo "\n\n"
    echo "ERROR"
    echo "-------------------------------------------------------------------" 
    echo "You typed: $GOVERNOR_TO_USE"
    echo "Please type number 1 (for powersave) or number 2 (for performance)"
    echo "-------------------------------------------------------------------"
    echo " "
    exit 1
fi
exit 0

markmarz wrote:

that, in combination with disabling the ondemand daemon, has nailed it!

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

Good to know, thanks!

markmarz wrote:

I can't execute the cpufreq-set command as detailed earlier.

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.

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

--produced an error message on my LinuxMint 17.3 (64-bit Cinnamon desktop edition) with Intel Core i7-3930K CPU @ 3.20GHz x 6. The following was repeated on standard output of the command-line linux terminal four times--

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?

--even a simple--

sudo cpufreq-set -c 0 -f 3.1GHz

--produced the same error message.

SO, I decided to resort to memory about shell scripting (from a long time ago; forgot how to increment a variable by one for each repetition of a loop and had to look it up), and wrote the following script so that I could enable the intel_pstate driver in the linux kernal by default (by removing "intel_pstate=disable" from the GRUB commandline for the kernel), and could instead change the intel_pstate governor at will after logging into the GUI desktop. The intel_pstate driver evidently allows only two CPU-frequency governors: powersave or performance

#! /bin/sh
# script to change intel_pstate CPU-core governors to "performance" instead of "powersave"
# save script as (for example) performance-governor in home directory,
# then in command-line terminal, in the directory
# in which this script was saved, execute the following--
#
# sudo cp performance-governor /usr/local/bin/
# cd /usr/local/bin
# sudo chmod a+x performance-governor
#
# execute the script by typing (in command-line terminal):
# sudo performance-governor

CPU_NUM=1
for GOVERNOR in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    do
        echo "Changing governor for CPU " $CPU_NUM " to performance"
        echo -n "performance" > $GOVERNOR
        CPU_NUM=$((CPU_NUM+1))
    done

This script when executed displays in the command-line terminal's standard output:

Changing governor for CPU  1  to performance
Changing governor for CPU  2  to performance
Changing governor for CPU  3  to performance
Changing governor for CPU  4  to performance
Changing governor for CPU  5  to performance
Changing governor for CPU  6  to performance

After running the script, the command cpufreq-info now includes (for each CPU core)--

  current policy: frequency should be within 1.20 GHz and 3.80 GHz.
                  The governor "performance" may decide which speed to use

--whereas before running the script, cpufreq-info included for each CPU: "The governor "powersave" may decide which speed to use"

This script works without having to disable the "ondemand" script in /etc/init.d/ (or the symbolic link to it in the directory for a specific linux runlevel). Instead, the ondemand script typically sets the CPU-core governors to either "ondemand" (for pre intel_pstate CPUs) or "powersave" (for intel_pstate CPUs), and the script above merely changes the text in the scaling_governor file for each CPU (in /sys/devices/system/cpu/cpu*/cpufreq/) to "performance", even if it was already set to performance

I haven't exercised these command-line scripting muscles in years! It was kind of fun.

Note added later: a more versatile and complete form of this script appears later in this discussion thread.

I can't execute the cpufreq-set command as detailed earlier.

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.

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.

Of course! I learned something in this thread, thanks to you and everyone else.

I can't execute the cpufreq-set command as detailed earlier. For right now I'm just using the performance governor and it's sticky, which was my main objective. Haven't noticed any problems when playing, but if I do I'll experiment. Probably I'll check out Stephen's approach to disable the governor.

that, in combination with disabling the ondemand daemon, has nailed it!

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

markmarz wrote:

Stephen_Doonan wrote:

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. ...

... 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?

Well, in my case I'm not using the older ACPI method to regulate CPU frequencies (I'm not even sure I could do so with the recent Intel multicore CPU I have, which includes the intel_pstate functionality; perhaps ACPI commands are ignored, although that's only a guess); I merely disabled the CPU frequency scaling that is automatic when the CPU includes the intel_pstate functionality, and the linux kernel recognizes that fact during bootup. This causes my CPU cores to operate at "performance" settings (manufacturer specified, but not overclocked frequencies) all the time. On my desktop computer, this works fine (so far). The primary advantage I see in disabling the intel_pstate CPU-frequency-lowering kernel driver is that I don't need to issue the commands to cause the intel_pstate governor to use the "performance" setting every time I login or reboot the computer; intel_pstate is permanently disabled, as long as I leave intel_pstate=disabled appended to the linux kernel command line.

I imagine that on a laptop computer, it might be preferable for the user to regulate the CPU governors as needed or prudent, or to have them automatically regulated (scaled) rather than the "brute force" approach of disabling the intel_pstate frequency-scaling completely.
---

Gotcha, thanks for the clarification.

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.

Stephen_Doonan wrote:

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. ...

... 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?

Well, in my case I'm not using the older ACPI method to regulate CPU frequencies (I'm not even sure I could do so with the recent Intel multicore CPU I have, which includes the intel_pstate functionality; perhaps ACPI commands are ignored, although that's only a guess); I merely disabled the CPU frequency scaling that is automatic when the CPU includes the intel_pstate functionality, and the linux kernel recognizes that fact during bootup. This causes my CPU cores to operate at "performance" settings (manufacturer specified, but not overclocked frequencies) all the time. On my desktop computer, this works fine (so far). The primary advantage I see in disabling the intel_pstate CPU-frequency-lowering kernel driver is that I don't need to issue the commands to cause the intel_pstate governor to use the "performance" setting every time I login or reboot the computer; intel_pstate is permanently disabled, as long as I leave intel_pstate=disabled appended to the linux kernel command line.

I imagine that on a laptop computer, it might be preferable for the user to regulate the CPU governors as needed or prudent, or to have them automatically regulated (scaled) rather than the "brute force" approach of disabling the intel_pstate frequency-scaling completely.
---

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. ...

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?

Boild down it is easy as this with intel_pstate scaling_driver:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

... then you get the best performance of your 4 intel cpu-cores.

If you like to watch the frequency of your cores in realtime I recommend the tool 'powertop'. Playing Pianoteq it outputs something like that on my Intel N2930 netbook:

            Package |             Core    |            CPU 0
                    |                     | Actual    2.1 GHz
Idle       100.0%   | Idle       100.0%   | Idle       100.0%

                    |             Core    |            CPU 1
                    |                     | Actual    2.1 GHz
                    | Idle       100.0%   | Idle       100.0%

                    |             Core    |            CPU 2
                    |                     | Actual    2.2 GHz
                    | Idle       100.0%   | Idle       100.0%

                    |             Core    |            CPU 3
                    |                     | Actual    2.2 GHz
                    | Idle       100.0%   | Idle       100.0%

cheers!

Thanks groovy, I'll check out powertop, sounds like fun.

The code you suggest is exactly what the script I posted does; that, in combination with disabling the ondemand daemon, has nailed it! Thanks for your help.

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.

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

... then you get the best performance of your 4 intel cpu-cores.

If you like to watch the frequency of your cores in realtime I recommend the tool 'powertop'. Playing Pianoteq it outputs something like that on my Intel N2930 netbook:

            Package |             Core    |            CPU 0
                    |                     | Actual    2.1 GHz
Idle       100.0%   | Idle       100.0%   | Idle       100.0%

                    |             Core    |            CPU 1
                    |                     | Actual    2.1 GHz
                    | Idle       100.0%   | Idle       100.0%

                    |             Core    |            CPU 2
                    |                     | Actual    2.2 GHz
                    | Idle       100.0%   | Idle       100.0%

                    |             Core    |            CPU 3
                    |                     | Actual    2.2 GHz
                    | Idle       100.0%   | Idle       100.0%

cheers!

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'

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