Polling too slow

Timur Born

Active 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.



 

Attachments

  • report_debug.7z
    82.4 KB · Views: 1

Martin

HWiNFO Author
Staff member
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.
 

Timur Born

Active Member
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.
 

Martin

HWiNFO Author
Staff member
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?
 

Timur Born

Active Member
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.
 

Martin

HWiNFO Author
Staff member
OK, I think I know what the issue is. Will try to improve this in the next Beta build.
 
Top