Vermeer Ryzen 5950x Unusual Frequency Values
Ok, so it may not be what you thought from the title. I've been digging through the Python code examples to try to get good output from the Ryzen SMU kernel module on my Ryzen 5950x. What I noticed was that obviously the address of each parameter register(?) was slightly off for my CPU as the output was jumbled. I had a desire to understand mostly PPT, EDC, TDC live power values and CPU voltages (SoC, VDD, Memory Controller, vCore and individual cores). Ideally, I'd like to be able to benchmark at different settings
Hypothesis
I've currently been going through attempting to tune PBO and this module will help me a great deal to track power in particular. I'm running Ubuntu 23.04. The 5950x is on an AIO and I've configured PBO with 200 Mhz max boost, scalar 10x and PPT 300, EDC 195, TDC 175. I have also undervolted my CPUs in curve optimiser, currently it's -5 on my best four cores -10 on the next best for then -15 on the rest. My guess is that the PBO and voltage curve offset configuration might have something to do with what's up with my PM table output.
Investigation
So, I did what anyone with a bit of Python programming experience does and dug through the dump and read output for the pm table to try to understand what might be different and try to line up my CPU SMU registers to output the values correctly.
PM Table
Here is the PM table dumps at idle and full load: 5959x_dump.tar.gz
Here was my guess at classifying the address ranges:
Voltage
Idle
0x02F0 -> 0.898423
0x02F4 -> 0.889735
0x02F8 -> 0.912343
0x02FC -> 0.901248
0x0300 -> 0.896049
0x0304 -> 0.897808
0x0308 -> 0.898747
0x030C -> 0.901968
0x0310 -> 0.873605
0x0314 -> 0.873541
0x0318 -> 0.873266
0x031C -> 0.871310
0x0320 -> 0.875653
0x0324 -> 0.871309
0x0328 -> 0.873403
0x032C -> 0.871502
Frequency
Full Load
0x0330 -> 77.641106
0x0334 -> 80.275223
0x0338 -> 81.887108
0x033C -> 85.692307
0x0340 -> 82.826424
0x0344 -> 85.937309
0x0348 -> 80.955795
0x034C -> 82.834663
0x0350 -> 79.540459
0x0354 -> 78.679070
0x0358 -> 84.533211
0x035C -> 83.287209
0x0360 -> 85.645851
0x0364 -> 83.824677
0x0368 -> 81.784966
0x036C -> 81.584160
Core Watts
Full-load
0x02B0 -> 11.983614
0x02B4 -> 12.166693
0x02B8 -> 12.126005
0x02BC -> 12.609056
0x02C0 -> 12.407557
0x02C4 -> 12.582647
0x02C8 -> 12.229378
0x02CC -> 12.373768
0x02D0 -> 10.617566
0x02D4 -> 10.578953
0x02D8 -> 10.880623
0x02DC -> 10.828976
0x02E0 -> 11.084096
0x02E4 -> 10.840137
0x02E8 -> 10.796768
0x02EC -> 10.842819
CPU Activity
Full-load
0x0470 -> 100.000000
0x0474 -> 100.000000
0x0478 -> 100.000000
0x047C -> 100.000000
0x0480 -> 100.000000
0x0484 -> 100.000000
0x0488 -> 100.000000
0x048C -> 100.000000
0x0490 -> 100.000000
0x0494 -> 100.000000
0x0498 -> 100.000000
0x049C -> 100.000000
0x04A0 -> 100.000000
0x04A4 -> 100.000000
0x04A8 -> 100.000000
0x04AC -> 100.000000
Max Boost (Matches my PBO setting roughly)
Static
0x0630 -> 5.250000
0x0634 -> 5.250000
0x0638 -> 5.250000
0x063C -> 5.250000
0x0640 -> 5.250000
0x0644 -> 5.250000
0x0648 -> 5.250000
0x064C -> 5.250000
0x0650 -> 5.250000
0x0654 -> 5.250000
0x0658 -> 5.250000
0x065C -> 5.250000
0x0660 -> 5.250000
0x0664 -> 5.250000
0x0668 -> 5.250000
0x066C -> 5.250000
Ok, this seemed like some progress.
Monitor CPU
To get this to script to start functioning on the 5950x, I added the Vermeer architecture into the codenames
array in the expected position so that it would pass the architecture test, obviously this indicates support for Vermeer in this script hasn't been sorted. I knew I'd be in for some trouble.
The values were all over the place for the core statistics, so I figured the address range of the values was off. I dug through the pm table dump code and found what "looked" like the CPU frequency as shown in the PM table section above. I modified the Monitor CPU script to match the address ranges:
def parse_pm_table():
codename = getCodeName()
ccds = getCCDCount()
cores = getCoreCount()
model = getCpuModel()
pm = read_pm_table()
while True:
print("\033c================ CPU INFO ================")
if codename != False:
print("Code Name: " + codename)
print("CCDs: {0} | Cores: {1}".format(ccds, cores))
print("Model: " + model)
totalA = peakFreq = i = 0
while i < cores:
freq = read_float(pm, 0x0330 + (i * 4)) * 100.0
activity = read_float(pm, 0x0470 + (i * 4))
power = read_float(pm, 0x02B0 + (i * 4))
if peakFreq < freq:
peakFreq = freq
totalA = totalA + activity
# I commented out sleeping for debugging purposes
print("Core #{:d}: {:4.0f} MHz @ {:4.4f} W ({:4.2f} %)".format(i, freq, power, activity))
i = i + 1
Observations & Questions
- Firstly, I noticed that the CPU frequencies were a power of 10 higher than I expected at idle ~3400 MHz. I reduced the multiplier to
100.0
to compensate this. I'm guessing this is not expected from the SMU pm table? - At full-core load using
stress-ng
the boost frequency is wild, between 7000-8700 MHz - this made we wondered what is the value that is returned scaled in an unexpected way, or if it was combining frequency together. It almost seemed like it was a bit short of double the all-core boost reported by/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
, usually 4400-4500 duringstress-ng
. As this is a power management value, could it be what the PM is requesting rather than what the core is doing actual? - When I ran a single core
nop
loop with C, to generate the highest frequency possible on my best core (cpu2
) the frequency hit about 5300 MHz in the output. During this time, I'm seeing about 5010-5020 MHz in the cpufreq system device. This is strange, and closer to what I expected - but once again, closer to the max boost value we'd expect with PBO and not the actual frequency. - The watt readings per core are what I expect and seem to line nicely with the total package power (PPT) and the Core power values.
- What are the CPU frequency values reported by the SMU? Are they actual or requested frequency?
Here's a short video on the boosting behaviour reported by the tool.
Overall, this project is super impressive and I'm learning a lot about Ryzen CPUs and the SMU in this process. Happy to provide any further data, dumps or do any testing. Any advice or ideas you can throw around would be appreciated.