Polling too slow

Timur Born

Well-Known Member
Hello,

on my W10 installation HWinfo's sensor polls/displays at slower rates than what is set up as Global polling rate. I reported this problem sometime last year and it is still present in the latest 6.34-4300.

- When the Windows system timer is kept to its default of 15.625 ms and all latency reporting sensors are disabled then HWinfo's polling rate needs to be set to about 660 ms to match a 1 second clock.

- When Windows system timer is set to 0.5 - 1 ms or HWinfo's Debug mode is enabled then HWinfo's polling rate needs to be set to about 900 ms to match a 1 second clock.

It does not matter if Debug mode actually writes a debug file or not (needs a restart of HWinfo to change that), it's enough to switch the option in HWinfo's preferences (without restart).

Furthermore I noticed that HWinfo latency reports in its headlines do not match the sub-entries even when all sub-entry sensors are disabled. So frankly, I don't know what to make of it and how (reported) sensor latency affects polling rates.

vHPbgJ0.png


HlqlRsN.png
 

Attachments

  • report_debug.7z
    82.4 KB · Views: 1
That difference between polling rate and actual scan time is due to the time it takes to read all sensors. HWiNFO does the scan synchronously, so it doesn't account for the time spent to read sensor data.
The other difference you observe when disabling all items except the heading it because even in this case the sensor (NVIDIA in this case) can do some global polling actions. You need to disable the heading too to completely disable polling the sensor.
 
Thanks for the explanation about sensor polling when the heading is still enabled. I suspected that, but wasn't sure.

That being said, for the polling timer test I did disable the headings already and the accumulated Profiling Time of all remaining sensors was less than 10 ms (more like <5 ms).

That difference between polling rate and actual scan time is due to the time it takes to read all sensors.
Then HWinfo takes about 340 ms to read all sensors when Debug mode is disabled and about 100 ms to read the same sensors when Debug mode is enabled (or Windows timer resolution increased)?

I did another test, this time I disabled even more sensors, only leaving CPU and C-State residency enabled. Polling still has to be set to about 740 ms in order to match a 1 second clock, but only when Debug is disabled. With Debug enabled polling has to be set to about 990 ms to match a 1 second clock.

To underline the main issue: Polling rate is much faster (closer to expected) when Debug mode is enabled or when Windows timer resolution is increased.

Furthermore, HWinfo reported 0 Profiling time over all remaining enabled sensors, while some scan (or processing?) time still seems to be involved.
 
This is most likely because there's a difference how CPU sensor values are read when Debug Mode is enabled and disabled. But actually I'd expect it to be opposite - faster without Debug Mode.
How many cores does your CPU have?
 
9900K, 8 cores / 16 threads. I appended a compressed (7Z) archive including both the report and debug files in the first post. That should answer all questions about my hardware setup. ;)

Debug mode behavior reflects behavior when the Windows timer resolution is increased to 0.5 - 1 ms. But timer resolution is *not* increased by Debug mode. When Debug mode is disabled and timer resolution is increased manually (TimerTool) then the higher the resolution (smaller ms) the faster HWinfo refreshes.
 
OK, I think I know what the issue is. Will try to improve this in the next Beta build.
 
I experience a similar issue using an AMD 5900X + W10 20H2 + HwInfo 7.03, but this time changing Windows timer resolution does not seem to have an impact.
 
Check the "Profiling Time" for each sensor if there isn't some taking excessive time to read.
 
Good call, there were two sensor categories listed as up to 90 ms. So I hid every sensor (category) that takes longer than 5 ms, that only left 2 categories at 4-5 ms (all sensors below that 0 ms) and one category at 1 ms, everything else is 0 ms. Still at 100 ms polling rate HwInfo only seems to refresh about 6 times per second instead of 9-10 times at 100 ms polling rate.
 
I still find this to be an issues. Now Windows 11 22H2 on a Z790/13th gen.

Why does HWinfo not subtract the sensor polling time from its polling rate to keep in sync? So if 1000 ms polling rate is set and all sensors take 100 ms to read, why not poll after 900 ms and thus stay at 1000 ms display rate?

And why does disabling all sensors with a latency higher than 1 ms (with a total latency well below 7 ms) still lead to quite noticable desyncing?
 
Because the time to read sensor data usually isn't constant and can change from cycle to cycle.
When all sensors are disabled, there's usually additional time spent to poll CPU and its cores which isn't accounted in the per-sensor polling time.
Windows isn't a real-time operating system and there are several other tasks running. So there are other factors playing a role like the scheduler and timer / task-switching granularity (usually 16 ms).
 
FYI, from the next build HWiNFO will attempt to match the polling period regardless of time spent to read sensors.
This might require you to adjust the current setting if you tried to account for the sensor readout time.
Anyway, an absolute millisecond precision is not possible to achieve under such multi-tasking systems but it might be somewhat improved by assigning a higher priority to HWiNFO.
 
Very nice. Of course we don't expect absolute millisecond precision. The biggest confusion currently happens when HWinfo polls notably slower than what is set up, because of sensor latencies that users (including me in the beginning) usually know nothing about. So from my point of view this is a welcome change, thanks again! :)
 
Last edited:
I tried the current Beta and noticed something I was not aware of before. This is independent of sensor latencies (only 0 ms sensors active):

When I create constant load with fixed CPU core affinity, like 3 hyperthreaded cores of load in OCCT (6 threads) then HWinfo's polling rate drops considerably. I tried to set HWinfo's own core affinity to an unused core, but it keeps resetting its affinity to all cores right away.

Here is an animated GIF showing 1000 ms poll rate vs. a clock while OCCT runs HT load (6 threads) on cores 0, 5 and 6.

dda5e979-7625-4f13-b26f-f369d006294b.gif

Here is the same poll rate after stopping OCCT (it does desync, but it is still considerably faster):
76f21764-74b9-499f-93c3-eebbbc195d9d.gif
 
HWiNFO needs the affinity to be set on cores it is currently measuring and it enforces that in each cycle. So don't try to change its affinity, you might get completely wrong results.
If some cores are under a very high load, the scheduler will not give HWiNFO a sufficient time slot, hence the delays. You could improve that by rather raising the priority (High or Real-time) of HWiNFO.
 
Increasing HWInfo's priority does not help, neither High nor Realtime. And OCCT's own load threads already only use priority 1 (base and dynamic) anyway. So there seems to be more afoot here than just scheduler time slots!?
 
Back
Top