I have an Arch Linux box with a 3950x that I use as a NAS and build server. I’m pretty sure I have PBO set up correctly in the BIOS, but no matter what I do, the CPU caps out at 3.5Ghz.
I’ve tried switching to different governors and changing settings in cpupower, but honestly I don’t have much experience with the linux kernel. I’ve also tried overriding the BIOS limits in /sys/devices/system/cpu/cpu*/cpufreq/bios_limit, but even as root I get a permission denied, and using /sys/module/processor/parameters/ignore_ppc doesn’t seem to work either.
How do I set it up so that it boosts to < 4GHz like it would do on windows?
This is my cpupower frequency-info output:
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: Cannot determine or is not supported.
hardware limits: 2.20 GHz - 3.50 GHz
available frequency steps: 3.50 GHz, 2.80 GHz, 2.20 GHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 2.20 GHz and 3.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency: 2.20 GHz (asserted by call to hardware)
boost state support:
Supported: yes
Active: yes
Boost States: 0
Total States: 3
Pstate-P0: 3500MHz
Pstate-P1: 2800MHz
Pstate-P2: 2200MHz
Kernel version is 5.12 and the motherboard is an Asus x570 Pro Ace WS for what it’s worth.
Here’s the root cause. Your hardware doesn’t support more then 3.5GHz. I don’t know where that limit comes from, it could be CPU, RAM or mainboard related, something else entirely or any combination.
Okay, ignore_ppc does work if I enter it manually (processor boosts to 4.2 on all cores), but my modprobe.d/ignore_ppc.conf file is not being loaded by the kernel on boot for some reason.
My suggestion is to turn off PBO, pick a manual cpu clock multiplier and set a reasonable Vcore voltage.
Currently run my 3950X’s with the per-CCX overclocking setting with the clock multiplier set at 43/43/43/43 on the latest 3950X that has two good dies. On the very early, older 3950X, I can only manage 43/43/42.5/42.5 and keep to a reasonable 1.28V Vcore.
For someone that runs all the cores at full load all the time, any of the AMD clock optimization algorithms is counter-productive. It will downclock to a lower frequency and yet still run at WAY too high a Vcore that causes too high temps and further downclocking.
The easiest way I have found to keep the cpus boosting all the time is use the cpufreq GNOME extension and set the cpu governor there to Performance instead of the default OnDemand governor. That way I don’t have to mess with the cpupower files in /proc. I am lazy and take the easiest path to gaining my objective.
Thanks, sounds reasonable. I have an 3950X, too. I tried the Clock Tuner for Ryzen tool that is available for Windows 10, but did not have much success. The tool was always telling me values for clocks and voltages and when I actually tried to set them in the BIOS the computer became unstable. How did you got to your clock speeds? I mean testing them for every CCX would have too many permutations.
Well, you can start with a benchmark load that is similar to your actual workload. Prime95 or my favorite, y-cruncher hammers all the cores similarly to what I do with my BOINC projects. 3 or 4 iterations of full suite passes through y-cruncher will tax your system with a variety of N32/N64/AVX/AVX2/FFT and Integer calculations. If you get through them all without errors you are stable.
See where the Auto functions end up with the core clocks and what kind of Vcore that requires.
Then manually try the same clocks and at progressively lower Vcore till you start making errors in y-cruncher. Then bump back up a few clicks in the voltage. Then run your normal workload and see if the host stays up and running.
Basically I try and stay below 1.30V for temp reasons and see what kind of clocks that will gain me and still be stable.
Doesn’t take longer than an afternoon and a couple of hours of try-testing.
Doesn’t require that many permutations. I already have a target clock speed that I want to achieve. Set the per CCX value for all the dies and get a failure.
Then drop down one multiplier level. Get stable. Then add back one multiplier level on a single die. Test and repeat adding the same multiplier back into another die. Fail and back off. Try another die. Bump again. Fail and backoff.
You can always add individual Vcore for each CCX in the setting too. I am lazy and don’t want to figure out the hex value for that voltage so just select Auto and let the cpu figure it out for me.
If you are running Linux and the Zen cpus, you really should use one of the cpu monitoring drivers. Either the asus-wmi-sensor kernel driver if you have one of the WMI BIOS supported motherboards like my ASUS Crosshair VII Hero board.
Or the zenpower and zenmonitor drivers.
asus-wmi-sensors
Gets you all the same sensors that HWinFo64 or HWMonitor gives you in Windows.
@cbc02009 I’ve seen this issue as well, try a kernel 5.4 and see if that allows your boosting behaviour to work again as expected. You’re the only person I’ve found that has mentioned this issue and I’m experiencing the same issue. With a 5.4 kernel all cores boost and scale according to load (PBO is enabled), with 5.10 and newer all cores are locked to one frequency, for example if I set the CPU governor to performance I get 3.3GHz all core locked (running a Ryzen 9 5980HS on a Asus X13 Flow), and during compilation I’d get 1 maybe 2 cores boosting to 4.4, 4.3, and everything else below locked at 3.3. If I enable powersave governor all cores go to 1.2GHz. All I could tell is that there is some performance regression with kernels newer than 5.4, and it could very well be that they target P-States explicitly and override the PBO behaviour.
And this is cpupower frequency-info output
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: Cannot determine or is not supported.
hardware limits: 1.20 GHz - 3.30 GHz
available frequency steps: 3.30 GHz, 1.30 GHz, 1.20 GHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 1.20 GHz and 3.30 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: 3.30 GHz (asserted by call to hardware)
boost state support:
Supported: yes
Active: yes
Boost States: 0
Total States: 3
Pstate-P0: 3300MHz
Pstate-P1: 1300MHz
Pstate-P2: 1200MHz