Ryzen 7 2700X CPUFreq Scaling Governor Benchmarks On Ubuntu Linux

[fmyhr]

I'd be interested to see total system power draw for your 4 test cases -- even a visual average from a $30 Kill-A-Watt (what I use!). Some of use DO care about power & efficiency.

[monte84]

As far as I know about it, the only thing that CPU governors can do to Ryzen is slow it down. If you put it in performance and leave it alone, it should use XFR and manage its own power.

With my 1700 that is not the case, if I use performance govenor I am clocked at my base frequency of 3.0Ghz. Even on a single thread.

CPUFreq Scaling Governor is an optional feature of the Linux kernel and slows down your computer. Use the hardware to control everything. Hardware solutions are better usually.

please share on how to disbale governors completely.

[dungeon]

please share on how to disbale governors completely.

If your kernel have CONFIG_X86_ACPI_CPUFREQ as module you can just blacklist acpi_cpufreq module, which should disable this completely.

Otherwise if like on Ubuntu kernels you can't as it is built-in into kernel, which means be happy to re/compile your own to be able to ditch that or at least to be able to test how it goes without for you

Watch CPU usage, power usage if you can... and in the end decide for youreself if you want this or not.

I don't share debianxfce opinions, kind of thinking feature might be useful for some laptops or for Desktop CPUs who suck too much power... otherwise there is possibility some don't need it at all, like on low power Desktops by design - there usually this does nothing much if at all other than it might produce inconvenience here and there particulary default ondemand which tries to be smart

Powersave governor i dunno for what it is and dunno who will use that most of the time, probably no one as if that is an idea then it is better to just buy lower wattage Ryzen and run it without it

[monte84]

I reset my UEFI back to defaults and I am not getting turbo clocks at all (regardless of governor), I am staying at base clock, which is 3GHz on my Ryzen 7 1700. Running cinebench in wine and the single core score reflects the turbo is not working. manually 3.7Ghz is 151 single core, stock UEFI is 121, which is 3Ghz, so I should be seeing around 151 if turbo is working.

[Brisse]

monte84 Which kernel are you on? There were issues with Ryzen boost frequencies which were fixed in linux 4.14.

[dungeon]

I reset my UEFI back to defaults and I am not getting turbo clocks at all (regardless of governor), I am staying at base clock, which is 3GHz on my Ryzen 7 1700. Running cinebench in wine and the single core score reflects the turbo is not working. manually 3.7Ghz is 151 single core, stock UEFI is 121, which is 3Ghz, so I should be seeing around 151 if turbo is working.

Is that happen everytime or on linux only. Here for example even on Windows, suddenly turbo is not there after reseting bios question:

https://community.amd.com/thread/216272

But then again, there is an answers like this

T I am not seeing anything wrong with the frequencies you've screenshotted there.
People seem to misunderstand XFR a great deal with Ryzen and retailers don't help by marketing the 1700 as a 3.7ghtz CPU which it's not, it's a 3.0ghtz CPU. Only one core can hit 3.7 (3.75 with XFR)
Turbocore clocks on the 1700 will up-clock ALL cores at once to 3.2ghtz, however XFR will ONLY work on ONE core and then ONLY when the other 7 cores are idle.
Your screenshot shows that core 0 had hit 3.749 at one point, that is XFR with the turbocore having bumped the others upto 3.2 as normal when all cores were used.
In other words, nothing is wrong, your CPU is behaving as intended.

Which makes me think maybe wine (or you, or your OS... ) do something on other cores, preventing turbo/xfr boost

[sdack]

Still nothing new. I'm rather looking forward to 4.17 and it's new power-saving ability.

I keep using on-demand with custom settings, and because it gives me these options. In my /etc/sysfs.conf do I have:

# 'ondemand' CPU governor, switch up at 50% load and stay up 10x longer
devices/system/cpu/cpufreq/ondemand/up_threshold = 50
devices/system/cpu/cpufreq/ondemand/sampling_down_factor = 10
devices/system/cpu/cpufreq/ondemand/ignore_nice_load = 1

[aufkrawall]

Are there any advantages of not compiling acpi-cpufreq over just setting governor to performance? I mean apart from some KB of additional memory usage.

[mlau]

Are there any advantages of not compiling acpi-cpufreq over just setting governor to performance? I mean apart from some KB of additional memory usage.

acpi-cpufreq is the module that knows how to actually set the processor speed. Governors without any cpufreq driver don't make sense. The Ryzens do set cpu speed
automatically based on demand though. I keep the performance governor set all the time, and as long as a core isn't in use, they clock down to 1800MHz automatically,
and, based on thermal budget, even the turbo clocks are reached just fine:

$ grep MHz /proc/cpuinfo | sort
cpu MHz         : 1887.258
cpu MHz         : 1888.794
cpu MHz         : 1892.149
cpu MHz         : 1894.881
cpu MHz         : 1922.980
cpu MHz         : 2012.816
cpu MHz         : 2046.824
cpu MHz         : 2069.944
cpu MHz         : 2143.843
cpu MHz         : 2144.853
cpu MHz         : 2181.461
cpu MHz         : 2184.688
cpu MHz         : 2428.357
cpu MHz         : 2460.288
cpu MHz         : 4290.951
cpu MHz         : 4299.466

So I don't know why debianxfce seems to have so many problems, I didn't change anything in bios/uefi at all and the Ryzen works as advertised. Just enable cpufreq, cpufreq-acpi driver, and add the performance and schedutil governors, make performance the default.

[monte84]

Somehow when I reset my UEFI i must have disabled Core Performance Boost. I then noticed that I would go up to 3.2GHz on all core load, however, when testing a single core, the clock speed was adjusting quite erratically between 3.3 and very seldom 3.69. likely averaging just under 3.5GHz on single core (I used taskset -c to set one core, else it would jump around from core to core and perform just a bit worse on the Cinebench test). On a crosshair vi with a phanteks ph-tc14pe.