Minimum time for adjustment stop

[Maccara]

Would it be possible to add one additional parameter to ProBalance settings:

"time required below CPU quota before adjustment stops"

I was hoping that "minimum time for adjustment" would already do that, but alas not (although it does help). (if it actually should do this already, I found a bug then ) (using v4 beta at the moment)

Reason for this: Some applications have short periods of time when they're not using the cpu (writing data to disk etc) only to resume the operation after that. With the current adjustment possibilities that causes ProBalance adjustment to stop only to resume adjustment a second later and this causes some minor hitches on my system (which is quite annoying). This parameter would allow to eliminate the "pogo effect" for these apps.

I can of course manually set default priorities for those processes (which I have done), but it would be nice to be able to automate ProBalance a bit more intelligently for these situations for completeness sake.

[Jeremy Collake]

First, let me say, sometimes the log entry timing is off just a little during high loads. That is a separate issue I am working on. Therefore, do not rely on log entry times to be precise indicators of when the actual adjustment happened (as of the last beta build).

If you raise this Minimum Time For Restraint value high enough, it should work. There are exceptions though, and one of those may be the culprit here (such as the restrained process being moved into the foreground). However, I am conducting a more thorough investigation and don't want to stick my foot in my mouth if I am wrong. You may also want to decrease CPU % before restoration. I will report more during the course of my investigation.

[Jeremy Collake]

Preliminary investigation has shown that the primary causes (as least in the limited environments I've tested in) is actually these:

• Restraint timing in the governor turns out to be accurate
• The logged time was/is slightly inaccurate during high loads
• The default value for the Minimum Time For ProBalance Restraint is set too low (I am doubling it)
• The per-process CPU usage before restraint ProBalance parameter is set too low for most hardware (I'm setting it based on hardware now

I may have more to add, or redact, later.. The pogo effect is due to these overly aggressive processes regaining monopolization for a brief period of time, which is why it is important for ProBalance to act earlier rather than later. In general, acting earlier causes no problems, but acting too late can be bad news.

[Maccara]

Thanks for checking this out.

Just a short clarification on what I mean and how I've tested this. I do not even need to look at the logs to see what happens.

Tested now with parameters: (in order as they're in GUI, and just to emphasize the point - not my regular tweaks)
60%,40%,20%,1100,180000,0

Then I had a couple of separate test cases with applications (1 multithreaded and other 2 single threaded eaters) that pause every minute for 5 seconds.

ProBalance kicks in as expected and stays on for the 3 minutes but after that it will happily end restraint as soon as eater enters pause stage (and falls below 20% cpu usage), even though the pause is only 5 seconds (rinse and repeat). <-- this is what I want to eliminate with the proposed parameter (or change how "min time for adjustment" is handled) as it causes annoying hiccups - especially when trying to watch a video at the same time.

Currently, no ProBalance setting solves this adequately and I have to rely on default priorities instead.

Hmm... Maybe if I just set "per-process cpu usage for adjustment stop" to 1% it would solve the normal pathological cases I see for the meantime.

[Jeremy Collake]

Oh, I see now. That makes sense. How about 'Consecutive time under quota before process is restored'? I think that is what is needed here. I can't guarantee I'll make such a large change in v4, as it is about to be released, but it is an easy change and I can quickly add it in the first minor update to version 4.

[Jeremy Collake]

BTW, if you were to raise the 'Options / General options / Recheck processes every' setting it could help your situation too .. BUT it would make Process Lasso less quick to kick in. If you set it to, say 10 seconds, then it would average CPU utilization over 10 seconds instead of 1 second. That means your paused process wouldn't look so paused, when looked at over 10 second periods.

Anyway, the final solution is indeed a new parameter or change to the operation of ProBalance. I will work on this after v4.

As you said, probably lowering the 'per-process cpu usage for adjustment stop' to 1% is indeed the best thing to do for now.

[Maccara]

'Consecutive time under quota before process is restored' sounds good! I realize this is not just a simple addition so late in RC (trivial to code, but you probably have to think how it works with other parameters and tweak the defaults etc etc) and I have workarounds, so take your time. Thank you very much!

And yes, increasing 'recheck process every' would probably work too for this simple test I did (didn't test, but would assume so), but that parameter also affects when probalance kicks in and I want that to be as low as possible. (and the real apps I would like this new parameter for would need the setting at somewhere around a minute, or even longer)

Btw, it would be great if 'recheck process every' setting would be separate from GUI update speed - I would like to lower it to 250ms even but the GUI is practically unusable under that condition.

Did some quick testing with 'per-process cpu usage for adjustment stop' and it seems to be an adequate workaround indeed. Some real apps hover around 3-8% cpu usage when they do their "idle stuff before going angry again" so a low setting of around 3% seems to do the trick for now. Low setting unnecessarily keeps some other apps restrained which wouldn't need to be, but combined with 'exclude foreground processes' and the fact that the priority is adjusted to below normal instead idle this seems to work fine for me for the moment.