Core Clocks accuracy/reliability

[Timur Born]

Hello.

There are three oddities about "Core Clocks" that make me wonder about accuracy and even reliability of the measurements. The following screenshots are on a 13900K. I may be understanding these wrong, though?!

1. Core Clocks may not catch maxima that Effective Clocks do catch.

True maximum 5600:



Expect behavior: Core Clocks' maximum should not be below Effective Clocks' maximum (or even its average).

2. "Bus-clock based" sometimes calculates non-integer values, even when "periodic polling" is disabled and the bus-clock was measured as 100.000 MHz at startup.

Maximum values:


Expected behavior: Core Clocks should only use multiples of the startup Bus Clock value when "periodic polling" is disabled.

3. Disabling "Bus-clock based" leads to unusable values (may need restart to reproduce).

100% C0 residency:


Expected behavior: HWinfo should be able to measure the Core Clocks without being Bus Clock based, or the tooltip should clarify that this may not work on new CPUs (instead of just stating the defaults).

Thanks and all the best!

 

[Martin]

1. Have you read: https://www.hwinfo.com/forum/threads/effective-clock-vs-instant-discrete-clock.5958/
2. Small variations are expected here. Later Intel CPUs perform periodic and quite accurate measurement of BCLK regardless of whether periodic polling is enabled or not.
3. It's not possible to accurately measure core clocks when Bus Clock based mode is disabled

 

[Timur Born]

Thanks for the quick answers.

1. So essentially it is "bad luck" when the Core Clocks multiplier maximum is not recorded at the time of the polling period. I could increase the polling rate then, but at the cost of creating more background load via HWinfo. I wish the Effective Clocks could be made to ignore C states, having multiple clock modifiers in one number can be confusing and sometimes even gets in the way of what one tries to measure.

2. I understood the tooltip of "periodic polling" in such a way that the Core Clocks multiplier only ever uses the startup value, regardless of later BCLK changes. I also wonder why my BLCK would religiously stick to 100.00000 MHz, except for occasionally measuring 100.02400 MHz for a single blib? Is this to be trusted?

3. Understood. Unfortunately the tooltip only mentioned the different defaults, but not the impossibility to measure without Bus Clock.

 

[Martin]

1. Not just bad luck. Another factor is when active polling of each core is performed to determine the "active"/legacy clock values, it puts some (even though minimal) load on each core. That can often result in waking up a sleeping core from a lower C-State, hence preventing the MCT (Muti-Core Turbo) to kick in.

2. That's the case of some CPUs where determining the actual BCLK is more tedious. Later Intel CPUs allow a quite lightweight method of measuring BCLK, hence this can be performed in each cycle. The advantage is that potential on-the-fly BCLK changes will be reflected.

 

[Timur Born]

1. Ah, yes. This makes sense and is one reason why I try to find a good balance between poll rates being too high (additional load) or too low (not enough information). But having the poll action itself cause clock changes wasn't on my list entirely. Does this "active polling" also happen for the "Ratio" sensors?

2. The tooltip might need some update then, because it currently strongly implies that a fixed startup BCLK is always used when "Periodic polling" is disabled.

Thanks again!

 

[Martin]

"Active clock" is always based on current ratio, so it's actually the ratio (multiplier) which is actively determined. The active clock is then just ratio*BCLK.
Intel CPUs don't have means to determine the full active clock value.
For AMD Zen this is possible and also performed when the "Snapshot CPU Polling" mode is activated.

 

[Timur Born]

Would disabling the Core Clocks (+Ring?) and Ratio sensors disable that extra polling load and thus increase accuracy of the Effective Clocks sensors (due to less Hwinfo load)?

 

[Martin]

No, this is also required for some other information, e.g. per-core temperatures, C-States, etc.
Even disabling all sensors won't prevent this kind of polling on Intel CPUs.

 

[Timur Born]

Thanks for the extra information. Increasing the polling rate to reduce noise on Effective Clocks seems like the best bet then. Unfortunately Effective Clocks still gets dominated by C states, which is a problem when a single thread of load is shifted between 2 HT cores of the same physical core (or different cores at slow polling rates).