Core effective clocks at 100% C0 state

[Timur Born]

I used 7.04 and Snapshot Polling in those screenshots. It's more of a report than a question about HWiNFO's different behavior compared to RyzenMaster. HI drops Effective Clocks considerably more when a core leaves C0 compared to RM (which often does not even budge).

Unfortunately it does not seem that C-states (other than C0) are counted as 0 MHz in the Effective Clock counter (average over its polling time). Else we could calculate "Effective Clock" / C0 Residency to calculate Effective Clock only in C0 state. But I tried that and the results don't make sense.

 

[Timur Born]

Try as I may, I could not find a correlation between HWiNFO's core effective clock, core C0 residency and core multiplier. Too bad.

 

[Timur Born]

I created these custom sensors to calculate clock stretching and visualize CCD differences. Anything below 0% is clock stretching (mostly) independent of C-states, listing the percentage of how much the effective clock is below the core clock. 0% is 100% C0 without clock stretching, effective clock is equal to core clock. Anything higher than 0% is C-states, but values higher than maybe 10% are useless (see below).

24 threads load:

5 threads load C-states enabled:

5 threads load C-states disabled:

Unfortunately they only work properly for core load close to (90-)100%, because of the way HWiNFO calculates HLT/sleep C-states effective clocks. Even though HWiNFO already is more sensitive to C-states than RyzenMaster the listed effective clocks are still too high in linear relation to C-states (Effective Clock / C0 Residency = too high). This means that numbers higher than maybe 10% are bogus values on my sensors, which then messes with averages. It still demonstrates that effective clocks are lowered by C-states, though, which is something many people on forums don't seem to know/understand.

On the other hand HWiNFO tends to hit a minimum effective clock of 0.0000 MHz even when C0 residency never hits a minimum of 0.00000% (unless core parking is enabled). This results in my sensors sometimes hitting down to -100% due to HWiNFO's effective clocks claiming to be 0 MHz.

This is still useful for testing PBO setting with high load. Tests like Cinebench 23 can already mess a bit with averages, though, due to lower load pauses in between each run while C-states are enabled.

 

[Martin]

Well, I have done some research and tests here and you probably won't accept this, but it looks like core clock stretching is no longer being used.
But there seems to be some other technique to reduce clocks, just not sure what.
Unfortunately I cannot reveal further details to you as this information is classified.

 

[Timur Born]

Thanks for the information and effort to investigate and share these things (as much as being permitted). I am interested in facts, not opinion, so I can perfectly well accept that something other than clock stretching (and C1) is used to reduce the effective clock. In the end it is just nomenclature and using DLLs to stretch PLL signals might come with its own disadvantages. Now I have to rename all my counters to "Clock Reduction".

Is there any chance that HWiNFO's effective clock numbers could get a linear correlation to C-states (and only display 0 MHz at 0% C0)? And/or maybe an optional switch to not have it include C-states at all but only clock reduction other than C-states (which my custom sensor tries do to)? Frankly I don't know what to make of the current numbers at low C0 residency, they tend to be lower than RyzenMaster, but still seem too high and thus kind of arbitrary.

PS: Renaming was not so hard, because I used Registry Finder to find & replace the corresponding data strings in one go. Such a great little freeware utility for Registry editing.

 

[Timur Born]

Today I observed the following max Effective Clock readings while C-states were enabled, Snapshot was enabled and CPU clocks were controlled by CTR. Unfortunately I did a reset after startup of HWiNFO, so it was at a later point after the start.

Maybe a collision with CTR running in the background? I cannot reproduce it at the moment, though.

 

[Timur Born]

Yep, conflict with CTR. Good to know.