Linux – Ryzen Bzy_MHz low when overclocked

amdlinux

I'm trying to overclock my new Ryzen 5 1500X, and after having the standard difficulties with lm-sensors not reporting CPU temps, I'm finding that I'm getting weird results from turbostat at certain overclocks. I haven't been able to find any information on what this means, online.

  • Kernel: linux 4.10.0-28-generic
  • Distro: Ubuntu GNOME 17.04
  • CPU: Ryzen 5 1500X (4 core, 8 thread)
  • CPU Freq: Stock 3.5/3.7 GHz; overclocked to 3.8-4.0 GHz)

I'm stress-testing using stress on all 8 threads, while trying to dial in an overclock.

At a 3.80 GHz overclock, turbostat reports normally that all 8 threads are running at 99-100% and Bzy_MHz is at 3799 MHz, which is fine.

At 3.90 GHz and 4.00 GHz, regardless of voltage, turbostat is reporting Bzy_MHz at 1378 MHz constantly. The output below is from a 4.00 GHz overclock, with stress -c 8 running.

CPU Avg_MHz Busy%   Bzy_MHz TSC_MHz
-   1378    99.99   1378    4000
0   1378    100.00  1378    4000
1   1378    100.00  1378    4000
2   1378    100.00  1378    4000
3   1378    100.00  1378    4000
4   1377    99.93   1378    4000
5   1378    100.00  1378    4000
6   1378    100.00  1378    4000
7   1378    100.00  1378    4000

Does this mean that the 4.00 GHz clock isn't actually functioning, or is there an error in turbostat's reporting?

I can't find linux-tools for kernel 4.11, so I can't run turbostat there. If it's a problem, would one expect it to have been fixed in 4.11?


EDIT: I've just run some benchmarks using Phoronix, and it seems turbostat is reporting the correct frequencies. The delta between my 3.8 and 4.0 GHz tests (both at 2.8 GHz RAM speed) is pretty much exactly what one would expect given the 1.4GHz reported frequencies for the 4.0 GHz "overclock".

This might not be a Linux problem, then, but I don't really want to set up a Windows partition or drive to test that out.

https://openbenchmarking.org/result/1707197-MARS-OC4000266,1707197-MARS-OC3800225

OC4000 and OC3800 benchmarks from PTS/John the Ripper. OC4000 averages around 37% of the OC3800 results.

Best Answer

After Googling after a BIOS update was released, this seems to be a Mobo and BIOS issue, and not a kernel issue as I was suspecting, which is massively reassuring.

Related Question