Easiest way to bump max CPU frequency?

[yoshimitsuspeed]

I am trying to overclock my CPU when I remember that frikken Linux limits CPU speed to a preset number based on your processor.
I remember years ago I used cpufreq to up that but then I remember it no longer scaled, just ran at 100% all the time.
I did some searching and found a dozen different suggestions that all seemed way overly convoluted. In the process I found /sys/devices/system/cpu/cpu0/cpufreq/ cpuinfo_max_freq which seems like it should be a simple elegant solution to upping the max limit but I cannot edit it. I tried sudo and su - with no luck.
I want scaling, I want it to work just like it does now. I don't want extra software or modability. I just want to up the max limit.

[oshunluvr]

If scaling is enabled with the default of "ondemand", you will go to your max limit when it's needed. If you want max all the time, set it for performance.

Install cpufrequtils and edit /etc/default/cpufrequtils to one of these: userspace conservative powersave ondemand performance

Then install sysfsutils and /etc/sysfs.conf. Add this line once per CPU (I have quad-core so I have four lines CPUs 0-3):

devices/system/cpu/cpu0/cpufreq/scaling_governor = performance

Obviously, if you want something other than performance use that. I'm running a desktop so I wanted max speed.

I also set these:

# Set permissions of suspend control file
mode power/state = 0664
owner power/state = root:admin

so I could check the state without sudo. I'm actually not sure if both of these packages are necessary. I'm pretty sure the second one will cover it, but I listed both to be sure.

Finally, if you're overclocking, linux will not show your actual CPU freq, it will show the max standard freq. To verify your actual freq, install i7z and run it.

[yoshimitsuspeed]

Linux does not recognize the overclock.

True Frequency (without accounting Turbo) 3291 MHz
CPU Multiplier 33x || Bus clock frequency (BCLK) 99.73 MHz
Should be 4600 mhz and multipier 46 but it doesn't recognize it.

[oshunluvr]

Linux does not recognize the overclock.

True Frequency (without accounting Turbo) 3291 MHz
CPU Multiplier 33x || Bus clock frequency (BCLK) 99.73 MHz
Should be 4600 mhz and multipier 46 but it doesn't recognize it.

Yes, that's what I said. Install i7z and it will show you the correct CPU frequency.

[MoonRise]

OK. Was always wanting to know that. So, installed what you said and edited fairly much all you said (will come back to this). Actually at konsole I used the cpufrequtils to manually change to performance. Great! Rebooted and looked at the current state and it appeared OK. Waited a few minutes and checked again and it was back to On Demand. Boooo! So, back to "fairly much all". On this part (Install cpufrequtils and edit /etc/default/cpufrequtils to one of these: userspace conservative powersave ondemand performance). I did not see that file in /etc/default. Do I need to create that file? Is this why it didn't "hold" my manually set configuration? I was able to edit the other file and set to performance for all CPUs but it seems maybe that is used by the system at boot and then something once you log-in overrides?



EDIT: That file is in /etc/init.d/ (at least for me). Rebooting to see. It was set at ondemand so I believe this overrode the other. Will know shortly.


EDIT: Nope. Every time it goes right back to On Demand. Any ideas?

[yoshimitsuspeed]

I just realized I have a locked I5 processor so even though it says it's overclocking in the bios it's unable to actually overclock.

Moonrise, I can't help you with your problem but I did find some discussions on the subject when I was searching for solutions to my problem. You might check out google and see what comes up.

[MoonRise]

Well after searching it lead me to this file --> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

It is used by the ondemand routine found here --> /etc/init.d/

From what I can tell these overide anything else being used, i.e. the settings and tools specified by Oshunluvr. I even found I had to create that one file myself. Which I did but it seems these are overridden by what I stated just above. You would think you can change the value in /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor which is set at ONDEMAND. Nope. I am editing it as ROOT but this is the error message I get.

The document could not be saved, as it was not possible to write to /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor.

Check that you have write access to this file or that enough disk space is available.

Now as ROOT you'd think I would but they evidently have it locked further. Why!?!?! So much for personal customization. I guess would have to write a script to use "cpufreq-set -c 0 -g performance" which is ridiculous when I should be able to use the "proper" files. Unless anyone has ideas how I can edit /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor?



EDIT: If you look in ONDEMAND routine it is allowed to "sleep" for a while during desktop loading and you can see that actually occur. Hmmmmmm, I wonder. Comment out everything in ONDEMAND. I'll give that a try. That did it. Happy!

[SteveRiley]

I suspect you guys are bumping into the Intel P-State driver, which completely replaces older methods for managing CPU frequencies in Linux.

From https://wiki.archlinux.org/index.php...uency_Scaling:

Starting with kernel 3.9, the new pstate power scaling driver is used automatically for modern Intel CPUs instead of the other drivers below. This driver takes priority over other drivers and in fact is inbuilt as opposed to being a module. This driver is currently automatically used for Sandy Bridge and Ivy Bridge type CPUs. If you encounter a problem while using this driver, add intel_pstate=disable to your kernel line. You can use the same user space utilities with this driver but cannot control it.

By extension, the last sentence implies that if you disable the pstate driver, you can return to the utilities you've used previously.

However: I would advise against this. Intel has been moving away from direct measurement and reporting of actual CPU frequencies, so trying to force the older tools to work with modern processors is probably not going to provide the results you expect. Intel's maintainer recently wrote:

The units for these for these files are purposely abstract and stated in terms of available performance and not frequency. In idea that frequency can be set to a single frequency is a fiction for Intel Core processors. Even if the scaling driver selects a single P state the actual frequency the processor will run at is selected by the processor.

[MoonRise]

Well what is odd then is the OS has this pre-existing routine that keeps a setting of ONDEMAND. I'm sure maybe to offer the backwards capability to older Processors? Either way perceived or not commenting out those lines in the ONDEMAND routine allowed me to use what Oshunluvr suggested or so it appears.



Edit: Thanks for the links. Interesting read.

[SteveRiley]

It's perplexing, yeah. I think we're in something of a transition now as p-state support is still "baking." A lot of the older scripts that worked with the older frequency drivers won't work with p-state; various tools try to make sense of what they see and report results, which can be incorrect. For example, consider:

steve@t520:~$ [B]sudo grep . /sys/devices/system/cpu/cpu*/cpufreq/*[/B]

/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:3023472
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:3400000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:performance powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:3400000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported>

/sys/devices/system/cpu/cpu1/cpufreq/affected_cpus:1
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq:942890
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq:3400000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq:800000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu1/cpufreq/related_cpus:1
/sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors:performance powersave
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq:3400000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq:800000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed:<unsupported>

/sys/devices/system/cpu/cpu2/cpufreq/affected_cpus:2
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_cur_freq:3158472
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq:3400000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_min_freq:800000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu2/cpufreq/related_cpus:2
/sys/devices/system/cpu/cpu2/cpufreq/scaling_available_governors:performance powersave
/sys/devices/system/cpu/cpu2/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu2/cpufreq/scaling_max_freq:3400000
/sys/devices/system/cpu/cpu2/cpufreq/scaling_min_freq:800000
/sys/devices/system/cpu/cpu2/cpufreq/scaling_setspeed:<unsupported>

/sys/devices/system/cpu/cpu3/cpufreq/affected_cpus:3
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq:1491960
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq:3400000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_min_freq:800000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu3/cpufreq/related_cpus:3
/sys/devices/system/cpu/cpu3/cpufreq/scaling_available_governors:performance powersave
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq:3400000
/sys/devices/system/cpu/cpu3/cpufreq/scaling_min_freq:800000
/sys/devices/system/cpu/cpu3/cpufreq/scaling_setspeed:<unsupported>

Four cores, each currently running at a different frequency. The indicated governor is performance, shouldn't all cores be maxed out? Nope, because the p-state driver is actually controlling the frequency. It probably doesn't even make sense to think about a governor when p-state is active. But not all of the tools or reporting methods grok this yet.

[MoonRise]

Thanks for that visual. I see what you mean and yes, they all should. Mine does but it is an older processor so may not be an issue after removing that silly make it ONDEMAND no matter what script. I'll have to use my work system to see what it reports when I make those changes. I bet it'll be what you are showing.

[gnomek]

I have E7400
http://ark.intel.com/pl/products/365...z-1066-MHz-FSB
Why the highiest frequency is only 2.67 GHz and not 2.80 GHz?
I did:

sudo apt-get install install cpufrequtils

sudo nano /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

lp

# Generated by sensors-detect on Thu Jul  5 10:47:57 2012
# Chip drivers
coretemp
it87

# Generated by sensors-detect on Mon Oct 13 18:04:36 2014
# Chip drivers
coretemp
it87

cpufreq_conservative
cpufreq_ondemand
cpufreq_powersave
cpufreq_stats
cpufreq_userspace
[Module from Step 3]

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance 

sudo -s
echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo conservative > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

sudo nano /etc/sysfs.conf

devices/system/cpu/cpu0/cpufreq/scaling_governor=ondemand
devices/system/cpu/cpu1/cpufreq/scaling_governor=ondemand

cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 160 us.
  hardware limits: 1.60 GHz - 2.67 GHz
  available frequency steps: 2.67 GHz, 2.13 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1.60 GHz and 2.67 GHz.
                  The governor "conservative" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz.
  cpufreq stats: 2.67 GHz:4,11%, 2.13 GHz:0,95%, 1.60 GHz:94,94%  (398)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 160 us.
  hardware limits: 1.60 GHz - 2.67 GHz
  available frequency steps: 2.67 GHz, 2.13 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1.60 GHz and 2.67 GHz.
                  The governor "conservative" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz.
  cpufreq stats: 2.67 GHz:3,23%, 2.13 GHz:0,23%, 1.60 GHz:96,55%  (312)

I wonder if cpufrequtils are really so "smart" to make the frequency higher at the right time and not to delay CPU work. In other words: would CPU run faster if cpufrequtils was set to "performance" (to the highest frequency)?

[SteveRiley]

The difference between 2.8 and 2.67 isn't much. Could be nothing more than different ways of reporting a number. Consider that hard drive manufacturers consider 1 GB to be 1000^3, while everyone else considers 1 GB to be 1024^3.

Also, it's unnecessary to peg the CPU at its highest frequency all the time. That generates heat and wastes electricity. Now that the kernel supports Intel's P-State scaling, we have a much better method (via the intel_pstate driver) to manage CPU power consumption. Essentially, let the system take care of itself. It's no longer necessary to use any part of cpufrequtils.