"Recheck processes every..." Question

[AtlBo]

Been experimenting with Process Lasso on a couple of PCs.  One is an old Pentium 4 1.5 GHz with 1.125 GB RAM, and the other a 2.13 GHz core 2 duo with 4 GB RAM.  I came to the conclusion that the "Recheck processes every..." setting could be safely set to 250 ms, and that made me a tad bit curious to know if Bitsum has tested Process Lasso at even faster check rates.

Any chance we might see lower check rates any time in the future?

[BenYeeHua]

I am not the dev, but I will say my comment about that, what might happen, if PL has been support lower check rates.

1.PL become a small CPU eater, as it switching too much and bite other threads, which causing larger cache miss and increased time to process.
2.Need more time to optimizing PL, so it don't bite too much CPU usage at lower check rates.
3.Memory usage increase, as the memory more easy to leak?(not sure about this one)
4.Need force lower Timer Resolution, which might making other software faster, but more power consumption.
And more than I know.

[edkiefer]

Been experimenting with Process Lasso on a couple of PCs.  One is an old Pentium 4 1.5 GHz with 1.125 GB RAM, and the other a 2.13 GHz core 2 duo with 4 GB RAM.  I came to the conclusion that the "Recheck processes every..." setting could be safely set to 250 ms, and that made me a tad bit curious to know if Bitsum has tested Process Lasso at even faster check rates.

Any chance we might see lower check rates any time in the future?

Well try this , go to Configuration and log menu and click on " manual edit the current ini config file " . now close PL completely .

Edit the line updatespeed rate under [Performance] section , save change and start PL again .

I tried with a 150ms value and it worked (ran faster than 250ms .

Than see if any improvement happens . One thing to look at is faster you set that value the more PL GUI will use cpu resources .

[Jeremy Collake]

Been experimenting with Process Lasso on a couple of PCs.  One is an old Pentium 4 1.5 GHz with 1.125 GB RAM, and the other a 2.13 GHz core 2 duo with 4 GB RAM.  I came to the conclusion that the "Recheck processes every..." setting could be safely set to 250 ms, and that made me a tad bit curious to know if Bitsum has tested Process Lasso at even faster check rates.

Any chance we might see lower check rates any time in the future?

The minimum allowed value is 100ms.

The effects of a faster polling frequency are most detrimental for the GUI. Given that, I will splice this setting so that you can independently set the polling frequency of the governor and the GUI.

[edkiefer]

The minimum allowed value is 100ms.

The effects of a faster polling frequency are most detrimental for the GUI. Given that, I will splice this setting so that you can independently set the polling frequency of the governor and the GUI.

Right, the GUI really eats cpu% once you get below 1 sec , just watch cpu usage % .

[AtlBo]

Support...

I assume you mean bad for the GUI of Process Lasso?

When you say the minimum allowed is 100 ms, does that mean that when I manually set the recheck rate at lower than 100 ms in the .ini configuration file, I will still be using a check rate of 100 ms as far as the system is concerned (not the Process Lasso GUI)?

I can understand limiting the GUI to 100 cycles per second...or whatever looks best, but I do like the option of experimenting with the recheck rate.

By the way, it wouldn't bother me if you included an explicit disclaimer on changing the recheck rate or on changing any particular value with Process Lasso.  If there is one already, I have not seen it.  You guys are breaking ground.  Actually, I think a disclaimer might have a beneficial side effect of users testing settings knowing that they aren't endangering the program project with their example.  They could be honestly more comfortable sharing their experiences, especially those with a nice test machine that isn't critical to their every day usage.

If the actual lowest recheck rate possible for the Governor is now 100 ms, perhaps you could open the door to some users to test faster rates.  I'd be all in for testing such as downloading a special interface with faster recheck settings.  Anything that benefits Process Lasso...

[Jeremy Collake]

I assume you mean bad for the GUI of Process Lasso?

I mean the GUI will consume substantially more CPU cycles, particularly while the main window is open. This will be bad for the entire system.

When you say the minimum allowed is 100 ms, does that mean that when I manually set the recheck rate at lower than 100 ms in the .ini configuration file, I will still be using a check rate of 100 ms as far as the system is concerned (not the Process Lasso GUI)?

The way I have it coded in the current version is that any value less than 100ms is considered invalid and it will use the default value of 1 second.

I can understand limiting the GUI to 100 cycles per second...or whatever looks best, but I do like the option of experimenting with the recheck rate.

In the next beta you can experiment with polling intervals of your choice.

By the way, it wouldn't bother me if you included an explicit disclaimer on changing the recheck rate or on changing any particular value with Process Lasso.  If there is one already, I have not seen it.  You guys are breaking ground.  Actually, I think a disclaimer might have a beneficial side effect of users testing settings knowing that they aren't endangering the program project with their example.  They could be honestly more comfortable sharing their experiences, especially those with a nice test machine that isn't critical to their every day usage.

Yes, I will add such a warning.

Thanks for the feedback!

[AtlBo]

Thanks

This whole idea of tinkering with the recheck is more or less new for me.  I have been running PL with the recheck set to 250 ms for about 2 months simply because the PC responds better and the temps are normal if not lower.  With PL at this recheck, the best way I think I could describe what has happened is that the OS has in that 2 months been able to read my usage patterns, when I don't think 5 years would have accomplished this without PL.

The steps forward and backward with this particular timing setting are obviously a little bit confusing to me.  I guess the changes that have occurred on the system so far threw me off with the recheck setting at 1 sec (when I set the recheck to lower than 100 ms).  I feel a little bit stupid thinking I was making the PC better at a lower recheck, when it was actually higher, but for me it's more validation of what PL has been able to accomplish with this system over the last 2 months.  The fact that I couldn't tell sort of reaffirms what I believed before about what was happening.  Temps were actually higher using the 1 sec recheck, which says alot.  I was attributing that to the increase pace of the check.  Overall, going to 1 second, in retrospect, is in the direction of what it's like to run the PC without PL after 2 months at 250 ms.  It's better with it on, but it runs much better than before this 2 month period of its use, even with PL completely shut down.

I am looking forward to experimenting with this particular setting.  Thanks for taking the time to take in what I was saying about the program.  I'll be testing at 100 ms for awhile.  One thing is for sure, I have a new look at higher temperatures using the 1 second recheck, especially considering they were a full 2 C lower using the 250 ms setting.  Has me even moreso looking forward to doing some testing.

[Jeremy Collake]

Those are interesting results. Every PC will be different, depending on what I have coined your 'executive environment' (combination of software, hardware, and user behavior). A lower refresh rate will increase CPU usage of the governor too, but since the governor uses so few CPU cycles, it doesn't amount to much of an increase in CPU consumption. It's plausible that the faster response by the governor is advantageous in your particular situation. I don't think you'll see any additional benefit when going below 100ms, but you can try.

Just FYI, the increase in CPU consumption by the governor and GUI is proportional to the refresh/recheck speed. At 100ms, the governor and GUI use approximately 10x the amount of CPU cycles they would use at 1s. So if the governor is using 0.01% of your CPU at 1s, then that's 0.10% at 100ms.

I'll upload the new beta as soon as possible and post here when it's available.

[AtlBo]

Yes, I am following you on all of this.

The thing is (the thing that gets me) is that it's all happening on a backdrop of a PC which is becoming more and more optimized...far over and above the normal Windows capabilities for achieving such.  So, if Windows has or can create levels of optimization, PL is giving Windows the ability to create much deeper ones that lead to much greater intuitiveness and therefore responsiveness from the internal PC software engine.  There is much more activity I believe happening in the RAM and page file...or at least much more significant and much more relevant activity in terms of intuitively based user related activity....also I believe more PC telemetry based activity too (how much RAM to devote to a program based on past response times of hard drive, processor, etc.)

By "levels of optimization" I would be referring to databases of information tied to user usage patterns used for placing information in RAM and in the page file.  These would be the kinds of changes a PC might make as a result of a repeated pattern of programs being used together or in sequence, etc.  Open the one and the RAM is set aside for both, etc.  I believe Windows can do this as well as make use of PC telemetry for optimization.  However, in all my years of using a PC, I don't think I've ever experienced it until I ran PL for the first time.  In fact, I had been for years searching for a program like PL, based on this assumption that I had that Windows could create an optimized environment for multi-tasking but that something was missing.  Nothing I tried came even close to working.  Not to flatter you guys, but I think PL is the miracle I have been looking for.  I suspected that it would take something extra to bring Windows to life.

As for the improvements I have noticed, they are across the board.  The most important ones are, of course, the multi-tasking/optimization improvements.  In usage terms these would be noticed in smoother mouse movements, scrolling, dragging windows, running features, and even game play.  These are things I am sensing, so sorry if the language is awkward.

I guess I'm trying to say that PL is a double benefit.  Without PL, the PC would still run better after any real amount of time using the program.  It probably wouldn't take long without it for the PC to begin stuttering, though, I think.  So PL is optimizing Windows, a system's programs, and the PC itself...actually this is a triangle of improved performance.

On the governor.  To me, that it uses fewer cycles than the GUI is a good thing.  This leaves room for experimentation with the governor.  However, the GUI is important, so in a weird way, I guess it's the actual governor, considering the PL governor can be set at any level down to zero, while it's the GUI that won't allow for this.  That's interesting to me and something to respect about the GUI I think.  If the GUI is hopelessly messy at any number of cycles under say 80, for example, then it would make sense to expect that a PC couldn't be optimized better with any lower recheck interval.

Yes, I am really looking forward to the Beta, so thankyou for saying you will post its release here.  Count me in line already.  Rechecks have me standing in line already LOL...

[BenYeeHua]

Interesting.
And yup, GUI is the weak point of PL...
Nope, GUI is all program of weak point, just open Windows Task Manager, change Update Speed to High, biting 2% CPU usage for updating.
----
OT:Did you try playing other thing, like 0.5ms Timer Resolution, keeping lower DPC delay, disable HPET or more?

[edkiefer]

AtlBo : what kind of system are you running on , that temps are affected , laptop ?

The governor is what important with the settings, it what controls how  responsive system gets .

[BenYeeHua]

AtlBo : what kind of system are you running on , that temps are affected , laptop ?

The governor is what important with the settings, it what controls how  responsive system gets .

Ya, might be the bios has a sensitive fan control?

[AtlBo]

BenYeeHua...
Haven't tried those others yet.  One thing at a time I guess.

ed...
HP DC7700 4 GB DDR2 RAM 256 MB NVIDIA Quadro NVS 290 graphics card

It's a small form factor office type PC.

I think of the governor as holding back the background noise happening on a system at any given time...not shutting things down...just restraining their processor usage and keeping it below a constant level of usage over time.  Constants are a nice thing, and I think Windows was missing one until Process Lasso came along.

Thinking of the governor as holding back the background noise, perhaps a comparison to Dolby noise reduction is an appropriate comparison for what I think is going on.  The (intentional?/unintentional?) coincidental reward by product is that PL strikes a chord with Windows.  It turns it into the equivalent of a car that never needs a tune up.  This is just a matter of idealized optimization...something we should all be expecting from our PCs, but we haven't been getting it from Microsoft or the manufacturers...

[BenYeeHua]

Yes, step by step.
----
Yup, as Microsoft changing too much for the windows scheduler will causing too many software can't running with newer Windows.
This is why Microsoft don't fix it and Process Lasso come out.

[Jeremy Collake]

Windows does keep a database of application and user activity for use by SuperFetch, ReadyBoost, and other optimization subsystems, that's true. One of the primary purposes of the governor being in its own process is so that it isn't burdened by the overhead of the GUI. Most of the CPU consumption by the GUI is when the main window is visible, and most of it is listview and painting updates. Moving your mouse around the main window will cause the largest spike as hot-tracking (highlight and underlining) and mouse movement messages are fed through the message pump.

The new beta will allow you to use a polling interval as low as 10ms for the governor, if that's what you desire. That would, in practice, set the governor to always active. It shouldn't be ideal for anyone really. I think 100ms is going to be the lowest value that anyone would want to use, though since the governor primarily uses a single thread for its work, the most severe effect possible would be 100% utilization by that single thread.

The new build will be uploaded in a few minutes.

[edkiefer]

yes, now you can set each separately .

Seems to be working fine .

[AtlBo]

Hello and thanks for updating us on the new beta...

My first go round with the beta.  What is the best tactic?  Should I install the beta in a separate location like C:\ or install the program over the current installation I have in Program Files?

[AtlBo]

OK...I installed the beta to the C drive and its components.

Yes, nice way to split the settings.  This definitely should be interesting.

I'm have set the PL governor recheck rate at 80 ms, and I may test some lower numbers later.  As I mentioned, I will be focused on temperatures.

I think it might take a couple of weeks for me to see where this goes...

Thanks Support for this beta feature.  I think there is a decent chance I'll be able to find settings that sort of wrap up the bundle on this PC...

[edkiefer]

whether I run beta or normal builds I use the auto update option . it is very solid updater and even though beta is beta its very rare to give issues .

[Jeremy Collake]

I don't want to damper enthusiasm, but CPU temperature should not be affected. I believe any variations in CPU temperature are not due to Process Lasso's actions  

I am not sure that the refresh rate is understood well or not. It probably is clear, but to any readers that don't know: The GUI and Governor both periodically enumerate all processes and check their resource utilization. This is called polling. It's not possible to do it any other way. The refresh rate is the time in between these re-checks of processes. Therefore, you could look at the loop as:

while(...)
{
   Check_Processes_And_Take_Actions();
   Sleep(REFRESH_INTERVAL);
}

[edkiefer]

I don't want to damper enthusiasm, but CPU temperature should not be affected. I believe any variations in CPU temperature are not due to Process Lasso's actions  

I am not sure that the refresh rate is understood well or not. It probably is clear, but to any readers that don't know: The GUI and Governor both periodically enumerate all processes and check their resource utilization. This is called polling. It's not possible to do it any other way. The refresh rate is the time in between these re-checks of processes. Therefore, you could look at the loop as:

while(...)
{
   Check_Processes_And_Take_Actions();
   Sleep(REFRESH_INTERVAL);
}

Yes, with the GUI, its pretty straight forward IMO , refresh is how fast the graph and other aspect of the GUI get updated .

With Governor  not so much as it has its own setting (probalance values ) ,time allowed over cpu quota  before adjustment and    min/max time for a adjustment ,
I would think you would need a refresh rate lower than any of those except the max time for adjustment which is 0ms .

Not totally sure what your real results would be if for example you set refresh to 2000 , I would think the Probalance values would now not be valid ?

Of course that is just a example , the default is 1000 (1sec) and it looks then would not affect the default Probalance as they are bigger ?