scan interval
- Thread starter gope
- Start date
Yes, this should be fixed in the new build as well. Sorry for the troubles caused..
If you need an urgent fix, then please get this build:
www.hwinfo.com/beta/hw64_396_1654.zip
I posted HWiNFO64 only now, let me know if you need a fixed HWiNFO32 too.
Let me know if there are any others issues...
If you need an urgent fix, then please get this build:
www.hwinfo.com/beta/hw64_396_1654.zip
I posted HWiNFO64 only now, let me know if you need a fixed HWiNFO32 too.
Let me know if there are any others issues...
Vomit
Member
No need for an apology, your doing a great job on a complex piece of software.
It is bound to have things that dont work as you intended, maybe things you didnt have time to test yourself. As your software gains users more things may come to light, its all on the road to perfection i suppose and i wish i was clever enough to make such software myself.
It is bound to have things that dont work as you intended, maybe things you didnt have time to test yourself. As your software gains users more things may come to light, its all on the road to perfection i suppose and i wish i was clever enough to make such software myself.
For me, sensor updating still doesn't respect the interval using 1657. Or rather, it -seems- like it. I'm sure you've troubleshooted my system before, MSI Big Bang XPower II, Intel x79 chipset. FWIW, The RSTe drivers that were updated about a month ago have fixed SMART inside hwinfo, so thats good, but unrelated.
My sensors seem to only update as often as the set Scan Interval plus about 0.6 seconds. During these 600ms, hwinfo takes a significant amount of CPU, about 30% of one core when set to 100ms, and 25% spikes when set to 5000ms.
Is this a limitation of my motherboard, or is it something that can be optimized within hwinfo? Do you need me to follow some special instructions to get a debug file useful to you?
My sensors seem to only update as often as the set Scan Interval plus about 0.6 seconds. During these 600ms, hwinfo takes a significant amount of CPU, about 30% of one core when set to 100ms, and 25% spikes when set to 5000ms.
Is this a limitation of my motherboard, or is it something that can be optimized within hwinfo? Do you need me to follow some special instructions to get a debug file useful to you?
Please understand that to scan the sensors can take some time, depending on which sensors are present in system. So it seems on your machine it takes about 600ms to scan all the sensors. I'm sorry, but I don't think there can anything be optimized further, because it's due to the nature of various sensors and how to read values from them. There are more types which require a larger amount of time and resources. What you could do is to walk thru all of them and click Disable Monitoring to see which of them takes the most time and causes the load spikes. Typically such examples are the EC and SMART sensors.
Martin said:My faultThere was a case where the PCH sensor reading on systems with Sandy/Ivy Bridge systems took unnecessary long. I'll fix this in the next build.
Thanks for the feedback.
You're welcome. SMART and the -big- Fintek sensor cause minor slowdowns for me too, but that's probably normal. To me, it doesn't have relevant information for my uses, so I disabled them too.
Similar threads
