Recent content by PiersJH

With the method I've posted/linked to, I've not seen reported VID (any of the VID readings), or more importantly Vcore go above 1.50000V. AMD's chipset driver package is fundamentally broken (just look at the current issues with the latest chipset driver package - they can't even create a driver...

Yes. The figure is only valid (if one considers it valid at all) with full (95%+) CPU saturation.

Can you backup your existing HWiNFO instance (if you want to keep existing settings), uninstall it, download the newest stable release, try again (don't change any I2C settings, etc.) and then post a full screenshot of all values with mixed use?

I believe I've found a fix for whatever the problem is. I tried most versions of HWiNFO64 going back to 7.16-4650. This version appears to be fine. And just to be sure, I uninstalled the version I was using - again - but this time also manually removed the Program Files directory, as well as the...

The problem seems to be the large delay. Previous versions of HWiNFO never required setting a higher priority, even with Prime95 small FFTs HWiNFO would update every second.

After observing the timer, with setting the priority as High, it's ticking over between 2,000 ms (as it should be), and 9,000 ms (which it shouldn't be). I've also noticed the new version of HWiNFO has odd clock reports in both the standard mode and Snapshot CPU Polling. BCLK is 100.001 and RAM...

Thank you for such a quick reply. I can't work out why reading the sensors would be taking longer. This happens at idle as well. However, I've just opened CoreCycler and it's saturating one thread (not core). The updates were happening about every 18,000 ms! I changed priority to Normal and that...

The timer at the bottom right of the Sensors screen no longer updates in real-time. The only change I've made is to enable SVM/virtualisation in the BIOS. This problem seems to occur sporadically, but is almost-always reproducible when running the CoreCycler script (which only uses 1 thread at a...

And after spending a couple of days testing, I found that Snapshot CPU Polling seemed to cause lag, or make the system less responsive. This was fixed by exiting HWiNFO, and then reproduced.

As the title says, what's the recommended polling period for storage (SMART)? I believe the default is - or was - 100, and I have it set to 2,500. Is there an ideal formula, for example where disk spin-down time * y = a less aggressive polling rate?

That makes total sense. I find the utilisation figures interesting when Snapshot CPU Polling is enabled - they tend to be lower. Here is a stock 5900X (PBO disabled, XMP enabled) running two instances of x265 (24 pools, heavily multi-threaded), yet the utilisation is reported ~15% lower with...

Ah, yes - I read that and then completely ignored it once enabled. Thank you. Is there a particular reason you set Snapshot CPU Polling to disabled as the default? The only reason I can think of is for people who see missing threads and panic.

That makes sense. Was the Core Effective Clocks area changed? I thought it displayed all threads, but now it shows only the cores.

Thank you - I was using 7.16 where the layout is different, and missed it. I've now upgraded to 7.20

I can't seem to find any option referencing Snapshop CPU Polling. Is it enabled by default on Zen-based CPUs?