Polling Period - Global vs Logging Cycle

[ddDerelict]

Short Preamble
Your info states a location of Slovakia. If you’re a native (I’m an American living in Belgium) your English is most impressive.

Thank you for this extraordinary suite of utilities – it has been my “go to” tool for about 5 yrs. I was pleased to see the addition of “Donate“ to your site and have done so (I clicked the “send me a “snail” mail etc” but you won’t find me by looking for a contribution from Belgium as my legal address is in Wyoming). I’ll also “make a plug” for the Donate business model here as it is the cleanest mechanism available for paying a product provider an amount of money commensurate with the value you’ve gotten from the product. And Yes, HWinfo deserves a donation.

FYI: in the following section of your home page the 1st and 2nd links resulted in “time outs”. The 3rd link worked tho.
See NASA references of HWiNFO in documents:
AMD Processor Radiation Test Results
Hardness assurance test results of an Advanced Micro Devices
Preliminary Radiation Testing CMOS Processor

I’m just technical enough to be dangerous!


My Question
I’m using Kombustor, Riva Tuner and HWinfo to test recently acquired GPU & monitor additions to my set up. I’m using HWinfo for monitoring/logging. As you may be aware In Kombustor the vanilla GL tests for the 1080p and 1440p Presets run for 60 seconds. I’m attempting to get a data set of 60 (CSV rows) to line up with the Kombustor test duration.

With Polling Period – Global at the default 2000 I get 18 rows of data in the CSV logging file that are clearly associated with Kombustor test. When the Polling Period is set to 1000 I get 25 rows, so obviously there is not a 1-to-1 relationship between Polling and logging. Thinking I might be able to do a Trend extrapolation in Excel with a third run I set the Polling to 500 with the following results (an X = data present in CSV, __ = no data under header; the listed data elements are all I’m logging):
X Date
X Time
X RAM Used [MB]
X RAM Available [MB]
X RAM Load [%]
__ Max CPU/Thread Usage [%]
__ Total CPU Usage [%]
__ CPU Package [°C]
__ Core Max [°C]
__ GPU Temperature [°C]
X GPU Core Voltage [V]
X GPU Core Load [%]
__ GPU Memory Controller Load [%]
__ GPU Memory Usage [%]
__ Total Errors []
__ Frames per Second [FPS]

I am at a loss. Is there some way for me to accomplish my objective with the tools I’m using or is this outside of HWinfo’s design scope?

Thanx in advance for your time & expertise.

 

[Martin]

Thank you for your kind words Yes, I'm a native Slovak.. And thank you for your donation too!
Regarding the NASA references: I have no problem opening them, the first two lead straight to a PDF document

Now to the main point - the polling/logging cycle. These are usually not absolute, especially in the case when reading data from some sensor takes more time. This adds then overhead on top of the period set, so if for example reading some sensor takes 0.5 seconds and your period is set to 2 seconds, the resulting log will be 2.5 seconds apart, in case of 4 seconds it will be 4.5 seconds apart.
To avoid such delays you might try to disable monitoring of some sensors (hit Del key over the heading), i.e. disk SMART which might be causing such delays. You can determine which sensors take more time to read by enabling the "Profiling Time" column, that will show you how long it takes to read any value/sensor.

 

[ddDerelict]

Thanx for the prompt response

RE donation: you're welcome; it is much deserved!
RE NASA; they are all working for me now also; probably just a NASA server maintenance thing.

RE Main point: I'll give that a try & update post with result ...

 

[ddDerelict]

Ok - after a bit experimentation this worked. I'll describe my journey in case it might be helpful to someone else ...

Unexpected hiccup
When first opening HWinfo's sensors I noticed that whilst the RTSS category was displayed the FPS data row was not. Performing some uninstalls (including deleting all found HWinfo references on the C drive/in the Registry) & re-installs (HWinfo, RTSS, MSI Kombustor and Afterburner) did not fix the issue. Neither did simply restoring the HWinfo folder in C:\Programs from a backup do the trick; a full C: drive restore did tho (which a key illustration of why I do daily backups).

Once I had a restored pristine version of HWinfo the fix was to open 1st Kombustor than HWinfo immediately after boot up and then run a Kombustor test. [Note: I have RTSS start on boot so it is always running before HWinfo is started.] After the test I again had the FPS data row pulling valid data. I don't know why the FPS data row disappeared in the first place but now it is still there even after a reboot and without running a Kombustor. There are a couple of possible culprits.

One is I've noticed that the Kombustor exe is 32 bit (downloaded the installer 2 days ago from the MSI site) whilst my machine is x64. Another is that I had completely customized the display order of HWinfo's sensors (enabled by unticking "fixed order" in Layout) and I may have inadvertently deleted (unticked Monitor & Show in Layout); since HWinfo is pulling FPS data from RTSS and I'd changed the order maybe HWinfo lost a pointer or something. [Note: running a Kombustor test while the sensor display was still heavily customized did not restore the missing FPS row.]

I have left the "fixed order" ticked since restoring HWinfo as part of a full C: restore.

Polling/Logging
TL;DR: set Polling to 533 & good luck.

Adding the Polling column to the sensor revealed one of my USB drives was taking >575ms to complete a cycle (SMART still shows "No" for Warning). As suggested above by Martin monitoring for SDD/HDDs was disabled. I also disable any major category from which I'd not be logging data. Major categories from which I would be logging data, however, I left "as is" since disabling sub-elements of a major category doesn't appear to alter the category's polling cycle time. The resulting log was not usable; the correct data headers were in the CSV but the data was either missing or in the wrong columns. The key seems to have been to identically align 1-for-1 what is being monitored and what is being logged.

That will properly populate the CSV.

Even at the default polling cycle of 2000ms my relevant reads went from 18 to 24 by simply aligning monitored & logged. Finding the polling cycle that would result in 60 reads/minute was simply trial & error. For me the magic polling cycle frequency is 533 ms. Somebody more technically knowledgeable than I am would know how transferable the 533 figure would be across hardware profiles but the mechanics of this approach should be transferable regardless of hardware profile. The approach has been validated by running different Kombustor Presets.

The 1440p result: