HWinfo64 slowing responsiveness

Started by edkiefer, August 14, 2014, 07:02:24 PM

Previous topic - Next topic

edkiefer

I was testing something with HWinfo64, just the sensor window open (was testing CPU V core andif worked with AB OSD .

Well I minimized it and forgot about it, I normally never use it for long time , just to do spot checking , I use OpenHardware monitor .

well my system started to get slow, which is very abnormal , and tried few thing ,then looked at PL graph and I was like what the hell half of graph was all yellow, not solid but in many sections with say HWinfo64 , hmm as soon as I closed it all was well , the CPU using was not real bad, many 20's % .
I have to try again to see whats going on but thought i post here this info or my results .
Yes, it seems it uses around 8-10% constant CPU usage , I even closed other HW monitors down but this is using a lot IMO .

On another note why is it getting restraint if only 10% ?

Ok, I found the culprit , it is the Asus sensors that use alot of cpu % .
what was happening, even though total cpu% seemed only max out below 20%, like 10-15% it was triggering up to a 27% setting in Probalance .

Anyway, it might be good to bring back the single process % field  even though nothing is wrong with PL .

I think what was slowing system down, was the 100's of log entrees that was being logged .
I closed/stopped PL core and now system is back even though cpu usage is around 15% max .

I enabled core but now its not doing it, might have to wait a while for many log entree's again , will report back on this .
Bitsum QA Engineer

BenYeeHua

QuoteOk, I found the culprit , it is the Asus sensors that use alot of cpu % .
what was happening, even though total cpu% seemed only max out below 20%, like 10-15% it was triggering up to a 27% setting in Probalance .
Motherboard sensors?

Anyways, I think you may wanna report to HWiNFO dev about this issues.

edkiefer

Yes, when you start up HWinfo64 sensor info window , a pop up comes up on Asus MB , that if you want to read these specific embedded MB values that it may cause a higher load and system may become unstable .

FWIW, here list of what Asus sensors it reads

Dram voltage
PCH voltage
CPU PLL voltage
VCCIO voltage

I have always used it with Asus sensors being read "but" I never had it running long as my primary HW monitor , so never noticed high cpu % , I think because it was just going over PL threshold 23% it was causing 4 files of logs to be writen and this was causing the slowness I saw .
I try again today, it doesn't happen ringt away ,as I stoped both HWinfo64 and PL and then restarted both and even though HWinfo64 was eating 8-10% it didn't affect anything . I lest it run a good hr last night but the new log files was still only 1k big .
Yesterday I generated 4 6k logs files .
Bitsum QA Engineer

BenYeeHua

Hmm, so it can be the ways that it read the sensor is unstable, I saw many MB software that read the value from MB will causing the CPU unsync, or tick much slower/faster, and causing software to having issues.

Anyways, you may try using PL watchdog to restart it automatic when it reach the CPU usage that it should not be. ;)
And ya, I think PL watchdog might need a new feature, restart the process based on how long did the processes has run. :)

So far I only monitoring the hardware by hearing the fan sound and how hot the surface of laptop is, as monitoring hardware can causing issues very easy, and only run HWiNFO and MSI AB/RTSS to monitoring via OSD, as I force the fan to run full speed. :D

edkiefer

I have them both running now but system is not having any issues , it took almost all day for me to see it, it was at night it started to happen .

the side affect is for example a delay in menu's and for example scrolling a long website scroll would pause for spilt sec , it even affect mouse .

I think its the log that are doing it . when it starts up I will close PL and see if that affects it, if its logs that will stop it, if not then its just HWinfo64 over time doing it, but i kind of doubt that, its not using much memory or anything .

Edit: here pic of PL

http://imgur.com/VJPfpZ9
Bitsum QA Engineer

Jeremy Collake

When I removed the exact ProBalance parameters, I intended to replace them with a slider to control the aggressiveness of ProBalance. I'll make this a priority; thanks for reminding me!

10% can be a lot when you consider that 12.5% would represent a maxed out single core on a 8 core CPU.

Also remember that lowering the process priority to Below Normal class doesn't normally slow anything down unless there is a lot of contention for the CPU. It's quite harmless. To have actual efficacy at retaining responsiveness, ProBalance needs to act a bit aggressively and proactively.
Software Engineer. Bitsum LLC.

Jeremy Collake

(addendum to last)

I have reduced the max log size in the most recent beta. Allowing it to grow so large could cause Lasso to act slowly at startup.

The overall system shouldn't be affected by Lasso's logging though. It's an idle priority thread and pretty well optimized. So, not sure that is the cause of any larger issues.
Software Engineer. Bitsum LLC.

edkiefer

Quote from: support on August 15, 2014, 12:38:47 PM
When I removed the exact ProBalance parameters, I intended to replace them with a slider to control the aggressiveness of ProBalance. I'll make this a priority; thanks for reminding me!

10% can be a lot when you consider that 12.5% would represent a maxed out single core on a 8 core CPU.

Also remember that lowering the process priority to Below Normal class doesn't normally slow anything down unless there is a lot of contention for the CPU. It's quite harmless. To have actual efficacy at retaining responsiveness, ProBalance needs to act a bit aggressively and proactively.
I fired up process explorer monitor and HWinfo64 is using 26% , PE has faster refresh than PL as I set PL to 5sec , so thats why it showing lowering values .
Still its been 5hrs so far , I see whats the cause, for sure HWinfo64 is using way to much %, but its good test to find anything we can improve on in PL .

Of course I could set HWinfo64 to below normal or exclude it but that would not stress test PL .

One thing that might help in this case is to have the log data in buffer/cache for a bit of time(10-30sec) so that if say you had 10 logs of same info on one process in 10sec , instead of logging each line it would say 10 instances of lower priority x time .

This would help when something is being logged a lot over time .
Bitsum QA Engineer

Jeremy Collake

Combining log entries like that is easier said than done. I tried to do that with the system tray tooltips. It really complicates the design. Just not worth it.

Thanks for the heads up, it's always interesting to hear what real world apps Lasso is acting on.

Speaking of that, I'm working on a new ProBalance Statistics dialog that will show in much greater depth what Lasso has historically acted on, and other statistics. I expect to have it available within a week, maybe sooner.
Software Engineer. Bitsum LLC.

edkiefer

right , I know that would be pain to code .Well lets see if i can reproduce what happened yesterday and then find whats true cause .

On below normal priority, yes most monitoring type app can be set to below normal , I was going to set them up that way.
Any that get suto started through scheduler gets them automatic to below normal by default .
Bitsum QA Engineer

BenYeeHua

Ya, I wonder can compress the old logs file will helps, as it is mostly the same process name and activity in this case?
So that you can just compress the old logs file to save some disk space. :)
----
And ya, did Process Lasso Trim itself, or it is because of the logs that is not write into Hard disk yet?
Because the Process Explorer and RAMMap is showing some part or memory is on the Modified page, and most of the time, it is because the process Trim itself.

That is nothing if the RAM is not using very heavy, as the data will be hold on the RAM, but when it is, the Modified page will be paged into PageFile, and causing the software that Trim itself start becoming lag, and it will need to read the data from Page File.

edkiefer

#11
ok, Update . So its been running since 8Am this morning , now 4:35 (8.5hrs) and still no issue like yesterday . but I did have 4 full logs files generated . I have generated 3 new 6k log files and one 50% so by tonight it will be more than yesterday .
If it log issue it should show .

Just played some BF4 too and i couldn't notice any issue .

My ram never goes more than 50% so there plenty ,especially if not gaming, when I had issue probably only 30% or ram was used .

I'll leave it run more but looks like it might of been fluke ,

Oh for record PL graph said my responsiveness (green line) was always 100%, too , it takes a lot for this system to go down with response .

Update, well after 14 hrs I can not reproduce issues I had yesterday , even though I have 6 log files today, so going to give this one to HWinfo64 fluke as its known issue to high resource usage with Asus specific sensors .
Bitsum QA Engineer

BenYeeHua

At least you know who caused it. :D
---
Talking about Responsiveness, I just think about a new feature.
1.When Process Lasso detect Responsiveness dropped from 100% to xx%, inform the user by using xxx/Balloon that it is happening and check the system. ;)
So far I am using CPU usage, not responsiveness on the Tray icon as it rarely drop, so this might be a good feature to get on PL.

edkiefer

yes , that is how i have it too, shows usage at icon .

That would be good for pop up message and guess log at that time or active window would show which process is issue .

It is really rare for me to see less than 100% responsiveness , even if I  try to bog system down .
Bitsum QA Engineer

BenYeeHua

Yup, except some hardware block happen(like reset the touchpad, which will caused no respond for any hardware a few seconds), or just boot from system, and the Harddisk is heavy load enough to prevent PL load the file from Hard disk, then it will drop.

But ya, if it drop for users like us(which has a good enough CPU and at least Win 7) that only happen very rarely, then it should really for us to check for it, and a function to remind/notice us is not a bad thing. :)