Refresh Changes for 6.03.13 Beta

AtlBo · April 19, 2013, 01:01:13 PM

Hello Support...

Got an idea that took me over this morning.

With the changes that have taken place in the latest Betas giving users the ability to use different refresh rates for the system and for the GUI, any chance we could see an overlay on the GUI graph that shows the refresh settings for each?

Perhaps the system refresh could be in yellow if it's not the same as the GUI refresh, etc., while the GUI is in green...

I really like the latest changes. Thanks. PC is running really well...

Oh...almost forgot...perhaps a check box next to the GUI setting on the graph to normalize the system setting to the GUI setting (make it the same/sync it with the GUI setting)?...

edkiefer · April 19, 2013, 02:35:42 PM

you mean like what we have with power profile ?

Since refresh doesn't change I am not sure it is that important to see overlayed .

With GUI you can see how fast graph updates as refresh for it .

AtlBo · April 19, 2013, 02:58:41 PM

Hello ed:
The refreshes for the GUI and for the governor can be set separately with 6.0.1.11 beta and so on, so I was suggesting a way to see if they are set the same on the graph...

edkiefer · April 19, 2013, 03:39:18 PM

Yes, I understand what you meant , sure it can be displayed somewhere in GUI, it could even just read the ini data value .

I meant I didn't think it needed to be overlayed on graph as it is static value (doesn't change once set ) .

AtlBo · April 19, 2013, 03:54:15 PM

OK I see what you mean.

Yes, I just was thinking it would be informative to see if the GUI refresh and the optimization process were set the same. Any way that it would be visible on the GUI someplace at all I think would be helpful. Sort of a way to keep things in perspective, now that the settings for the GUI and governor refreshes are separate and could potentially be different...

AtlBo · April 20, 2013, 01:24:00 PM

Just saw that an overlay on the graph when the governor is off has been added to the the 6.0.3.15. This accomplishes what I was hoping for, so thanks to Support for this addition...

Jeremy Collake · April 21, 2013, 04:27:34 AM

Quote from: AtlBo on April 20, 2013, 01:24:00 PM
Just saw that an overlay on the graph when the governor is off has been added to the the 6.0.3.15. This accomplishes what I was hoping for, so thanks to Support for this addition...

That's actually always been there.

I like your idea here! I will see what I can do to add some information about their respective refresh rates.

p.s. Speaking of refresh rates, I am considering making the default governor refresh rate 500ms. Perhaps only when there are 4 or more logical cores.

edkiefer · April 21, 2013, 08:13:45 AM

Only thing I seem to notice when using out of sync refresh rates is the graph % might not show up as point of trigger/restraint .

Meaning for example I have GUI on 2sec and governor on 500-1000ms , you will see a restraint on graph with low cpu% (cpu% line) , this is of course normal because your losing peaks with slow graph refresh . Just a side affect .

I hardly use graph so no problem here and honestly not to many restraints ever get trigger on my system , mainly browser .

BenYeeHua · April 21, 2013, 08:15:18 AM

Quote from: Support on April 21, 2013, 04:27:34 AM
That's actually always been there.

I like your idea here! I will see what I can do to add some information about their respective refresh rates.

p.s. Speaking of refresh rates, I am considering making the default governor refresh rate 500ms. Perhaps only when there are 4 or more logical cores.

And this is my result.

Using Process Explorer with 1 sec refresh rate to check the CPU usage of the thread.
i5-3210m
CPU usage(%)
1s(default)-0.05
100ms-jumping between 0.39-0.46
500ms-0.09

I also found that changing the governor refresh rate don't apply real-time, it need a restart of Process Lasso.
Did it expected?

Jeremy Collake · April 21, 2013, 08:30:36 AM

Quote from: BenYeeHua on April 21, 2013, 08:15:18 AM
I also found that changing the governor refresh rate don't apply real-time, it need a restart of Process Lasso.
Did it expected?

This is on my list of test cases. It may not be taking effect immediately right now, though it's supposed to. I'll add a log entry to notify when this is updated.

edkiefer · April 21, 2013, 08:34:58 AM

Quote from: BenYeeHua on April 21, 2013, 08:15:18 AM
And this is my result.

Using Process Explorer with 1 sec refresh rate to check the CPU usage of the thread.
i5-3210m
CPU usage(%)
1s(default)-0.05
100ms-jumping between 0.39-0.46
500ms-0.09

I also found that changing the governor refresh rate don't apply real-time, it need a restart of Process Lasso.
Did it expected?

Yes, you have to restart it it seems .

I see 0.11-0.12% for 100ms on core and 0.02% for 1sec on core . but that is looking at GUI, didn't check with another app

Edit: get 0.03% with 1sec on core in PE , 0.05-0.06avg (0.04-0.07%) with 500ms on core and with 100ms on core get 0.23-0.25%

that is with just browser open and not doing much , I did think i got more log actions with core set to 500ms verse 1sec , more priority lowering but its hard to say .

So seems fine scaling wise and that is on a i5-3570k running idle 1600mhz

AtlBo · April 21, 2013, 11:32:54 AM

Well, all I can say is thanks to Support for listening to ideas. The thinking for this idea was really just simply that a user could sort of keep track of how the governor refresh rate measures against the GUI refresh rate. Maybe it would help a user settle on a GUI setting? The check box was something of a potential way for a user to easily sync the processes if for some reason said user had been testing a governor setting, for example.

Jeremy Collake · April 21, 2013, 12:32:10 PM

I've fixed the issue with the governor not changing refresh rates until it is restarted. It will be in v6.0.3.19 beta (NOT yet uploaded).

@Ed: Thanks for the feedback. I also don't see any problems at 500ms.

@AltBo: Yes, I am considering ways to best depict this now

BenYeeHua · April 21, 2013, 02:36:05 PM

Yup, so 500ms is a good choose.
----OT line
Let me type it before I forget again.

1.Increase the time to restrain "that" process if the same process is restrain many time in a short time like 5 times in 30 sec
I found this is happening for some game, when you are opening it at the background, you will see the log is spamming.

2.Temporary lower the refresh rate if there are many process is restrain in a short time.
I wonder this can to accept?
As doing this will increase a little chance to increase the CPU usage and switching threads to governor more times, which might increase a little cache miss for other process???

And, a question.
Did the process being restraining will be release, after you switch to that process(foreground)?
And did it being release by immediately, or the next refresh rate?

This is what I can recall right now.

Jeremy Collake · April 21, 2013, 05:53:39 PM

Quote from: BenYeeHua on April 21, 2013, 02:36:05 PM
1.Increase the time to restrain "that" process if the same process is restrain many time in a short time like 5 times in 30 sec
I found this is happening for some game, when you are opening it at the background, you will see the log is spamming.

Yea, I've seen similar cases. I maybe should do as you suggest, or perhaps some tweaks to the ProBalance parameters would handle this case fine. I need to do a new review of the defaults there, but won't do it this iteration, I already have too much in progress.

Quote
2.Temporary lower the refresh rate if there are many process is restrain in a short time.
I wonder this can to accept?
As doing this will increase a little chance to increase the CPU usage and switching threads to governor more times, which might increase a little cache miss for other process???

Dynamically adjusting the refresh rate is an option, though I'll have to consider the implications carefully. Yes, an increase in refresh rate does cause the governor's thread to wake up more often, which could cause a small and short performance hit in certain high loaded situations. That's one reason it is important to find the right balance in refresh rate.

Quote
Did the process being restraining will be release, after you switch to that process(foreground)?
And did it being release by immediately, or the next refresh rate?

Yes, and on the next iteration (refresh). Trying to do it instantly would introduce a whole new level of complexity, and probably a DLL injected into every process to make the foreground switch event driven instead of polling driven. I could accelerate the foreground change check thread so that it checks more often than the main thread's refresh rate.

BenYeeHua · April 21, 2013, 07:02:47 PM

Thank for answer it.

So mostly the governor do its jobs on every iteration, to reduce the CPU usage?
---OT line
Because the increase of timer resolution and dynamic tick of windows 8 reduce power usage.

Or it just reduce the power usage because the CPU can deep sleep longer, not the CPU usage reduced because of reduced cache miss?

AtlBo · April 21, 2013, 07:36:04 PM

Don't know if this kind of information helps, but I will post my ProBalance settings, which I changed a little bit. These are the ones I have been testing refresh rates using:

System CPU to begin adjustments-default 45->my setting 38
Per Process CPU to begin adjustments-default 32->my setting 31
Per Process CPU when adjustment should stop-default 7->my setting 5
Time allowed over CPU quota before adjustment allowed-default 1100->my setting 800
The minimum time for an adjustment-default 4200->my setting 4500
The maximum time for an adjustment-default 0->my setting 0
Governor refresh rate-20 ms

I'm not having any situations so far. The governor kicks in every two or three seconds on one process or another, but I am not surprised by this. To me this is part of a larger optimization process that is happening. Also, the governor is not causing any performance problems. Actually, there are far fewer problems for me using these settings than otherwise. The ProBalance settings (1-6 above) could perhaps be tweaked, but I am experiencing good performance with them so far.

I'm not among the concerned (if there are any) over a percentage or two of CPU use, much less tenths of a percent, etc. PL is pushing Windows to read my usage better on this PC, and the primary catalyst is the refresh rate. For this reason, I would opt out of a dynamic refresh personally if there were an option for the feature.

Support, thanks for all the work you've done with Process Lasso. If you need any testing, I will be happy to push the limits for you to see how things affect a core 2 duo PC.

Jeremy Collake · April 22, 2013, 07:57:10 AM

Quote from: BenYeeHua on April 21, 2013, 07:02:47 PM
Thank for answer it.
So mostly the governor do its jobs on every iteration, to reduce the CPU usage?

Yes, for most everything. The things that *can be* event driven are event driven. That isn't much, sadly. The process stats simply have to be re-polled. The CPU utilization is quite negligible, and reducing even further in this beta series.

Quote
Because the increase of timer resolution and dynamic tick of windows 8 reduce power usage.
Or it just reduce the power usage because the CPU can deep sleep longer, not the CPU usage reduced because of reduced cache miss?

I don't know. I am surprised it has a positive effect on power utilization. It *may be* that the CPU frequency is able to be scaled more efficiently, and same for parking. That is much more likely than anything to do with the CPU caches.

edkiefer · April 22, 2013, 08:32:52 AM

Lets not forget that we do want ever process to process its instructions as fast as it can, we don't want to restraint to much, just enough to keep input lag and response good .

Settings best for each configuration is probably going to be tough one as there single, dual, quad etc with all varying speeds along with OS .

I think default is pretty good now , of course users can always tweak there values to see if can improve , you just don't want to be restraining to much and slowing down the processes (I have not seen this but again have not tried to make that happen altering the values, ) just saying .

BenYeeHua · April 22, 2013, 03:26:47 PM

A little OT, but still about hardware.

Quote from: Support on April 22, 2013, 07:57:10 AM
Yes, for most everything. The things that *can be* event driven are event driven. That isn't much, sadly. The process stats simply have to be re-polled. The CPU utilization is quite negligible, and reducing even further in this beta series.

Ya, I think the issue is cache miss.
Just watching many people saying FX-8320/8350 is snappy.
And it just like, same performance, a fast single core CPU vs many core.
The result is cache miss kill the single core, except you return to past, which don't has scheduler to support multi-task.(A.K.A real-time system)

QuoteI don't know. I am surprised it has a positive effect on power utilization. It *may be* that the CPU frequency is able to be scaled more efficiently, and same for parking. That is much more likely than anything to do with the CPU caches.

Yes, but I think, it only works when the computer is idle.
Because you just open a browser, the Flash Player+some website using setTimeout() and setInterval() incorrectly.
A browsing of internet is using the 1ms....
But, dynamic tick making the timer resolution more advanced, if you set as 1.5 ms, then it is 1.5 ms, not 1ms like windows 7.
And, I am still not sure about why Windows 8 increase the timer resolution to a strange value, like 1.001ms not 1ms.

http://www.nczonline.net/blog/2011/12/14/timer-resolution-in-browsers/
http://forums.guru3d.com/showthread.php?t=368604 - Must read

I will try to collect this information to a single post, and I has some issues on the other side, give me some time, but I am not sure that side of issues will be fixed, or dead.
----

Quote from: edkiefer on April 22, 2013, 08:32:52 AM
Lets not forget that we do want ever process to process its instructions as fast as it can, we don't want to restraint to much, just enough to keep input lag and response good .

Settings best for each configuration is probably going to be tough one as there single, dual, quad etc with all varying speeds along with OS .

I think default is pretty good now , of course users can always tweak there values to see if can improve , you just don't want to be restraining to much and slowing down the processes (I have not seen this but again have not tried to make that happen altering the values, ) just saying .

Thank for remind that, I has a little bit over about this.

The issues is, that game that I use for test is using that CPU usage constant, and I don't play that game on that time.
Maybe we can provide a "I don't CARE!"process list, which allow to increase the restraint time for process that we only care about when it is foreground, which means it has some poorly design(like game), when we minimize it, it don't has a power save mode to save power.