CPU Clock Measuring / Fault readings with new update 3.87

mididoc

Well-Known Member
hi,

the v 3.87 reads the core freq and multiplier wrong.
we have set the multiplier to constant max (25-26)

hwinfo shows in new update toggling between 12 and 25, 26
cpuZ shows the real constant 25 multiplier.

if i downgrade to hwinfo 3.86 it reads the same like cpuZ.

look in the code.

cheers
 
RE: Fault readings with new update 3.87

Yes, v3.87 introduced a new method for measuring CPU clock speed. This method should be more accurate for systems with Nehalem and Sandy Bridge CPUs.
The 12x multiplier which you see might be the EIST triggered LFM clock when there's no load on CPU. So are you sure your CPU doesn't lower the clock when idle?
AFAIK, CPU-Z doesn't refresh the clock as frequent as HWiNFO does, so that might be the reason why you don't see the 12x fluctuations there.

Please answer the following questions:
1. What CPU do you have and what Operating Points are reported by HWiNFO. Is 25-26 the Turbo Mode ratio?
1. How have you set the multiplier to constant 25-26 ?
2. Do you have SpeedStep enabled ? If yes, can you try to disable it ?

Also, you can still switch to the previous method used when you disable the "From Bus Clock" option in settings.

Anyway, I still think this new method should be more accurate and able to better reflect idle situations, because the previous one could itself trigger Turbo Boost when the CPU was set to high performance (Energy Performance Bias / Turbo Boost Technology engagement policy set to engage quickly). That means, measuring of CPU clock using the previous method results in putting some load on the particular core and when the CPU was set to such sensitivity, the measuring method would report a higher clock (up-to Turbo mode). Thus the previous measuring method influenced the measured system which has now been reduced to absolute minimum using the new method (From Bus Clock).
 
RE: Fault readings with new update 3.87

Martin said:
Yes, v3.87 introduced a new method for measuring CPU clock speed. This method should be more accurate for systems with Nehalem and Sandy Bridge CPUs.
The 12x multiplier which you see might be the EIST triggered LFM clock when there's no load on CPU. So are you sure your CPU doesn't lower the clock when idle?
AFAIK, CPU-Z doesn't refresh the clock as frequent as HWiNFO does, so that might be the reason why you don't see the 12x fluctuations there.

Please answer the following questions:
1. What CPU do you have and what Operating Points are reported by HWiNFO. Is 25-26 the Turbo Mode ratio?
1. How have you set the multiplier to constant 25-26 ?
2. Do you have SpeedStep enabled ? If yes, can you try to disable it ?

Also, you can still switch to the previous method used when you disable the "From Bus Clock" option in settings.

Anyway, I still think this new method should be more accurate and able to better reflect idle situations, because the previous one could itself trigger Turbo Boost when the CPU was set to high performance (Energy Performance Bias / Turbo Boost Technology engagement policy set to engage quickly). That means, measuring of CPU clock using the previous method results in putting some load on the particular core and when the CPU was set to such sensitivity, the measuring method would report a higher clock (up-to Turbo mode). Thus the previous measuring method influenced the measured system which has now been reduced to absolute minimum using the new method (From Bus Clock).

1) I have a i7-960, 25,26 is turbo
2) I set this in BIOS multiplier to max (CPU-Z reports right)
3) SpeedStep is disabled
 
Can you please post a screenshot of the System Summary window when the clock drops to 12x ?
 
According to that screenshot, HWiNFO seems to be correct - the CPU really switches to LFM due to SpeedStep (EIST).
Please also note, that EIST is enabled in your system as reported by HWiNFO. If you disabled EIST/SpeedStep in BIOS, then it means the BIOS doesn't really disable it which causes the clock switching.
 
Martin said:
According to that screenshot, HWiNFO seems to be correct - the CPU really switches to LFM due to SpeedStep (EIST).
Please also note, that EIST is enabled in your system as reported by HWiNFO. If you disabled EIST/SpeedStep in BIOS, then it means the BIOS doesn't really disable it which causes the clock switching.

I did not disable EIST/Speedstep.

I enabled High performance which sets the multiplier always to max.

This is explained like this in the intel board and i can verify in CPU-Z.
 
I think that just means the Turbo Mode engagement policy is more agressive, but it doesn't avoid switching to LFM in idle mode due to EIST.
You need to disable EIST too in order to keep the CPU running always at the deisred clock rate (however this is not power effective).
There is no guarantee that CPU-Z reports the correct clock, I also think that the clock measuring refresh rate in CPU-Z is rather low.
What says ThrottleStop ?
 
Martin said:
I think that just means the Turbo Mode engagement policy is more agressive, but it doesn't avoid switching to LFM in idle mode due to EIST.
You need to disable EIST too in order to keep the CPU running always at the deisred clock rate (however this is not power effective).
There is no guarantee that CPU-Z reports the correct clock, I also think that the clock measuring refresh rate in CPU-Z is rather low.
What says ThrottleStop ?

downloaded throttlestop
indeed it shows throttling level 12x up to 26x
same readings like hwinfo

cpu-z shows 26x

since the system is throttling in a fast change between 12 and 26,
cpu-z seems to be too slow and displays just the max.

why the settings in the dx58so2 bios do not set to a permanent speed at 24 or even 26 i don't know. but may be it is not so important for performance.
on my old asus p5e3 deluxe this was possible, but in reality it did not effect lot of performance win. the programs who need performance work with multi cores anyway and tune the cpu like they want.

however,
hwinfo reads the right values.
 
Thanks for the feedback. I'm glad that the new feature I implemented is an improvement and provides even more accurate information.
 
Martin said:
Thanks for the feedback. I'm glad that the new feature I implemented is an improvement and provides even more accurate information.

since 3.87

3.86 reads wrong.

:cool:
 
Back
Top