ProBalance Defaults and CorePrio questions

[shm0]

Hi!
On a fresh install of Process Lasso, ProBalance -> 'Per Process CPU Usage' (sorry I don't the correct translation) is set to 20%
When the default settings are restored it is set to 8% (maybe others values are also off)
Which value is the better one to use?

And can I use CorePrio to prioritize one core per CPU package first?
(e.g. CPU 0, 2, 4, 6 and so on)
Does "Enable Bitsum's Dynamic Local Mode' need to be enabled to make CorePrio actually work?
Is there a log somewhere?
Do you plan to integrate CorePrio into Process Lasso?

Thank you.

[Jeremy Collake]

I'd use the lower value, though either is fine. For some user, the higher value might be preferred, but generally you want ProBalance to be able to act before a load ramps up too high. There is also no real penalty if it were overly-active.

We'll evaluate how the defaults may differ on install and make a fix as appropriate. Thank you for reporting that. EDIT: This discrepancy in defaults now been fixed in 9.7.0.49 beta.

Yes, "Enable Bitsum's DLM" needs checked else CorePrio won't do anything. You can view Coreprio activity with SysInternal's DebugView (https://docs.microsoft.com/en-us/sysinternals/downloads/debugview). You'll need to run it as admin and turn on 'Options / Capture Global Win32'.

At this time, integration of CorePrio into Process Lasso is not imminent, though certainly on the radar.

[shm0]

Thanks for your reply.

You can view Coreprio activity with SysInternal's DebugView (https://docs.microsoft.com/en-us/sysinternals/downloads/debugview). You'll need to run it as admin and turn on 'Options / Capture Global Win32'.

But this doesn't show which processes/threads get assign to each core?

I checked  "Enable Bitsum's DLM" and set "CPU Affinity Mask" to 55 and "Threads to prioritize" to 4.
This should distribute threads over Core 0,2,4,6 first and then over 1,3,5,7?

[Jeremy Collake]

That would migrate the 4 most active software threads to logical cores 0,2,4,6. The system's scheduler would then place other threads elsewhere, where the load isn't as great. So, yes, it would work like that.

The default output may not be verbose enough for you. In principle, I should add a verbose switch to enable additional logging, but that hasn't been done at this time.