Effective clock vs instant (discrete) clock

Martin

HWiNFO Author
Staff member
It has become a common practice for several years to report instant (discrete) clock values for CPUs. This method is based on knowledge of the actual bus clock (BCLK) and sampling of core ratios at specific time points. The resulting clock is then a simple result of ratio * BCLK. Such approach worked quite well in the past, but is not longer sufficient. Over the years CPUs have become very dynamic components that can change their operating parameters hundreds of times per second depending on several factors including workload amount, temperature limits, thermal/VR current and power limits, turbo ratios, dynamic TDPs, etc. While this method still represents actual clock values and ratios reported match defined P-States, it has become insufficient to provide a good overview of CPU dynamics especially when parameters are fluctuating with a much higher frequency than any software is able to capture. Another disadvantage is that cores in modern CPUs that have no workload are being suspended (lower C-States). In such case when software attempts to poll their status, it will wake them up briefly and thus the clock obtained doesn't respect the sleeping state.

Hence a new approach needs to be used called the Effective clock. This method relies on hardware's capability to sample the actual clock state (all its levels) across a certain interval, including sleeping (halted) states. The software then queries the counter over a specific polling period, which provides the average value of all clock states that occurred in the given interval. HWiNFO v6.13-3955 Beta introduces reporting of this clock.
Many users might be surprised how different this clock is in comparison to the traditional clock values reported. But please note that this effective value is the average clock across the polling interval used in HWiNFO.
This new method has been tested on several CPUs and has shown to provide more accurate results especially in scenarios with extremely fluctuating values.
For example on Cascade Lake-X running a 1C workload, the effective clock provides values closer to specified 1C Turbo ratio limit, while (due to heavy fluctuations enforced by power limits) the discrete method only occasionally is able to sample the highest ratio.
On Zen2 (Matisse) systems this method can provide results closer to Ryzen Master (RM) per-core clock values, especially because it respects sleeping cores. It is assumed that such cores are marked as sleeping by RM when the effective (average) clock is below a certain threshold (somewhere around 50 MHz and below). Please note, that RM uses a different (proprietary) technique to measure clocks, so there might be some differences between the effective clock in HWiNFO and RM. While we work with AMD on the best way to access more accurate data to measure clock and voltage values, this remains the only method. Additionally, the current effective clock method is an architectural feature meaning that it doesn't depend on a certain CPU model, but is rather universal across a broad range of CPU families.
 
Last edited:

t0yz

Member
Very interesting to see numbers as low as 2MHz on my 8700K. I expected that the minimal frequency, even when idle, was similar to the lowest multi, for Coffee Lake seems to be 8x.

 

Martin

HWiNFO Author
Staff member
Very interesting to see numbers as low as 2MHz on my 8700K. I expected that the minimal frequency, even when idle, was similar to the lowest multi, for Coffee Lake seems to be 8x.
The Effective frequency does not represent a particular real clock, but the average clock value where sleeping states do not contribute to clock.
So for example when a core is running: 800 MHz, 0 (sleep), 0 (sleep), 0 (sleep)
the average value (effective clock) is: (800 + 0 + 0 + 0) / 4 = 200 MHz
 

Zach

Member
Just download the beta 6.13.3970... Great job again, and thanks for this awesome tool!
Is it possible to add a "Total CPU effective clock" like RyzenMaster report?
I've read above that RM uses different technique to mesure this.
The RM calculates all threads available together or just the actual/physical cores? Can we see both individually plus a "Final Total effective clock"?
(asking too much?):p

HWiNFO64 v6.13-3970 Sensor Status [4 values hidden] 04-Nov-19 15_40_16.png
 
Last edited:

Martin

HWiNFO Author
Staff member
I don't know how RM calculates this, but it's most probably using a different internal technique.
Hence I'm not sure what their meaning of Total effective clock is - whether it's just the average value of all core clocks or something else.
 

Zach

Member
I understand...

Another thing now that we are on the subject of speeds
I can see the last added #perf order of cores matches the max speeds of "Core clocks" for the most and less capable cores.
But always when idling or doing very light stuff the core #5(6th) and 5th in max speed/perf#, always have the highest speed for the Avg and now in the new "effective clocks" have also the highest Low/Avg. RM also states this.

What is that about? I know already that the Windows scheduler is far from be optimized for Ryzen 3000series and to which core to load for what. Is this "normal" and what I think it is, or is something else going on?

AMD RYZEN MASTER 04-Nov-19 16_18_42.png AMD RYZEN MASTER 04-Nov-19 16_38_11.png

Just realize something...
The RM is not stating the total effective CPU speed but the effective speed of the highest speed core as you will see in pics above... the 6th core, the one I'm talking about.
 

Zach

Member
I can understand if you are not allowed to discuss certain things especially not HWiNFO related.
Anyway that issue I've been talking about has been fixed just yesterday...
Tried it and it works. At least for the load of the capable cores part.



Now back to my request...
What I was talking about, is to have just a calculation of all the core/threads effective clock to one, actually 3 sums...
1. Each individual effective (physical)core clock sumary divided by their count.
2. Each individual effective (logical)core clock sumary divided by their count.
3. Each individual effective (physical+logical)core clock sumary divided by their count.

...all of them provide a current, min, max, avg value.

Edit: typo
 
Last edited:

Martin

HWiNFO Author
Staff member
I will add the 3. (total) average value in the next build.
I don't think the other two would have any reasonable meaning.
 

Zach

Member
Thank you very much for this, I appreciate it.
My thought for all 3 of them is to be able to see in various situations/workloads how the CPU is reacting with the physical and logical cores/threads. 1. and 2. especially...
For no particular reason. I'm just a geek who likes to observe these kinds of things. I like to try to understand things that interest me and how they work.

Thank you again and keep up the good work!
 

LowerMoon

New Member
I'm a bit confused about the perf clock readings for my CPU(3700X). So I found that the effective clocks closely match the readings from Ryzen Master (Thank you for that addition Martin). So basically, the perf clock readings show the instantaneous values and not the average of clocks over a certain interval, they also display the last clock of the cores right before they go onto "sleep" mode. And I do see the max values in my perf readings is 4.4GHz(as advertised). So my confusion is, when I have to see what's the max clock achieved by my CPU, I can, without a doubt check the perf readings right?

This is the dumbest question here, but I had to ask it, 'cause from the past few days I've been breaking my head over why I wasn't achieving the advertised speeds in Ryzen Master for both all core and single core(all core I'm getting only between 4.00 and 4.05, but that's a different discussion). I was almost convinced that my CPU was faulty. If my cores are able to reach 4.4, then I just gotta figure out why my all core speed is not up to the mark.
 

Attachments

Martin

HWiNFO Author
Staff member
"Core X Clock" values are the "old/traditional" values based on actual core ratios, which do not respect sleeping states or might not reflect highest clocks in case they are fluctuating.
The "(perf #n)" values just specify the (favored) Core Performance Order numbers, so kind of core quality rank, similar to what RM shows.
 

LowerMoon

New Member
I see, and the ordering happens based on the highest clock achieved by each core - whichever hits 4.4 first. So I guess I can conclude nothing is wrong with my processor, and the cores do indeed reach 4.4GHz. I can sleep well knowing that tonight. Thanks Martin, for your excellent tool.

Here's a fun fact: I contacted AMD tech support and sent them the exact screenshots, they specifically asked for HWinfo snapshots. And they concluded that my processor was working fine. Which is what brought me here.
 

Martin

HWiNFO Author
Staff member
The Core Performance Order is fixed, defined during manufacturing process depending on core "quality". Those with lowest index can achieve higher clocks at lower voltage.
 

Zach

Member
I see, and the ordering happens based on the highest clock achieved by each core - whichever hits 4.4 first. So I guess I can conclude nothing is wrong with my processor, and the cores do indeed reach 4.4GHz. I can sleep well knowing that tonight. Thanks Martin, for your excellent tool.

Here's a fun fact: I contacted AMD tech support and sent them the exact screenshots, they specifically asked for HWinfo snapshots. And they concluded that my processor was working fine. Which is what brought me here.
Like Martin said it is defined by the silicon quality which core clocks higher, medium and lower. What is not defined is which core will take the most load in a not all core load situation, like what I discussed in post #6. Its a Windows thing and more or less windows doing it randomly without actual sight (proper communication) to the high quality cores.
And you can see that on you screenshot with the core5 (perf #6) having the highest effective clocks (high/avg) meaning getting the most load, where perf #1/2/3 should get the most.
This has been fixed, and you can give it a read to the article on post #7
I suggest to read it all if not already.
 

Martin

HWiNFO Author
Staff member
Well, according to some others (I just had a talk with The Stilt), the 1usmus power plan is no miracle and doesn't work as expected.
The issue with assigning load to proper cores might be a BIOS/SMU or Windows scheduler problem as there are discrepancies in certain settings provided to the OS. It is not clear yet where exactly the problem lies.
 

Zach

Member
I'm sure its deeper than "just" a power plan, which by the way includes some BIOS settings about P/C states in order to work the best possible way.
Thing is that I installed it and its doing what its supposed to do. Is this the best way possible? probably not... as it involves a lot of parameters.

Before 1usmus power plan
HWiNFO64 v6.13-3970 Sensor Status [4 values hidden] 05-Nov-19 00_03_42 (2).png

...after
HWiNFO64 v6.13-3970 Sensor Status [4 values hidden] 05-Nov-19 00_24_31 (2).png

You can see it by the "max effective clocks" and the "max thread usage". ...just dont mind the avg values because there is a huge difference in time (on) duration between those last 2 screenshots. first is a few hours and second less than 1 hour.
Its not only assinging load to the high quality cores but also trying to keep things mostly to 1 CCX to keep latency low as possible. Thats why he stated that this works better on 2CCD/4CCX CPUs like the 3900X and the upcoming 3950X.
Its a start... IMHO
 
Last edited:
Top