Reset core when it reaches threshold?

AussiePatriot · October 03, 2014, 05:59:04 AM

Hi all,

I'm completely new here to using this tool Project Lasso. It looks like its a tool that allows a lot configuration to the user, which can be good and bad lol. But I'll get straight to my question.

Is there a way to reset a CPU core being used by a program (game) if that 1 core reaches 100% threshold?

I ask this because with the game Splintercell Blacklist, once you've loaded into the level and start running around the CPU core(s) behave normally, but as soon as I restart a level or die or restart from a checkpoint I can see 1 of my CPU cores always throttling at 100% for no good reason. If I disable then re-enable that CPU core it behaves normally again until I restart or reload again.

Help anyone??

edkiefer · October 03, 2014, 06:57:07 AM

I don't have that game , but many games, especially ones coded on older engines, they will do most rendering off one thread/cpu .
This generally is not a problem as system should be able to handle it unless it has thermal problems .

Is this a laptop of some kind ?

Anyway I don't think PL can do much now with this type of problem, AFAIK this is governed by how game is coded and how OS multi tasks CPU load .

AussiePatriot · October 03, 2014, 07:12:11 AM

I'm playing on my desktop system. Before I reload a checkpoint in the game, the game itself seems to spread the CPU load around quite well. But as soon as I reload a checkpoint, bam I can see that Core 0 is throttling at 100%. I can notice that when that 1 CPU core is trottling (even though non of the other cores are not) I can notice an almost microscopic stutter occasionally. its not game breaking at all, just barely noticable enough for me to see. I just thought that with PL it has a lot of functionality maybe it could help.

My specs:
Windows 7 Ultimate
Gigabyte Z77X UD3H
Intel 3770k OC~4.7
8GB G skill sniper RAM
Gigabyte Windforce3 GTX 780

edkiefer · October 03, 2014, 07:34:29 AM

Ok, that is odd, when you say throttling, you mean your reaching 100+C , hitting TDP limit .

Just trying to think how or what might be able to fix this externally of the game . The problem is you need it to do it w/o stopping the game and loosing your place on map .

AussiePatriot · October 03, 2014, 07:45:36 AM

By throttling I mean 100% CPU core use.

I can make a quick vid and upload it to uTube later so you can see exactly what I mean.

AussiePatriot · October 03, 2014, 10:36:01 AM

There is an option called "configure process watchdog" under options at the top.

If only there was an option to create a new rule that when an assigned core reaches an assigned workload then to be able to set affinity to only the other 3 cores I have. Then if I could make another rule that when the core that has been disabled by they first rule is not under any load at all to have the new rule activate the disabled core again.

as Of now PL doesn't have an option to create rules on individual cores, only a total percentage workload of all cores. If only I could make a rule for an individual core...

Hotrod · October 08, 2014, 01:54:00 AM

Have you tried the "change affinity during ProBalance restraint" options in the General ProBalance Settings?

Menu>Options>ProBalance settings>Configuration dialogue(general ProBalance settings)>Change affinity during restraint

There are 3 options including a round robin. There are affinity options in watchdog rules, but I wonder if maybe these 3 options could be enabled on a per process basis?

Jeremy Collake · October 08, 2014, 11:13:23 PM

The OP scenario sounds strange.

To be clear, what do you mean by 'disable'/'reset' a core? Do you mean change the CPU affinity? If not, what software are you using to toggle the core's status, so I am clear on what the operation is?

Hotrod's suggestion would be ideal *if* ProBalance is acting on the game process during this period. You'd have it temporarily change the CPU affinity along with the priority, problem solved. However, I fear that the game process is most likely excluded from ProBalance at the time the described scenario occurs, since it's a full-screen game.

You can also use the Watchdog Rules to some effect. You could have the game process change CPU affinity when it exceeds %x CPU use for y seconds. Unfortunately, it uses the 'total CPU use' metric , so you'd have to set 1/x, where x is the number of cores. For instance, 25% to indicate the full utilization of a single core on a 4 core system. Therefore, it may 'misfire', triggering this change in CPU affinity at other times during game play.

I believe that better understanding the problem here will result in a superior solution that may or may not be along the lines you suggest.

AussiePatriot · October 12, 2014, 12:20:24 AM

Hi guys thankyou all for the replies,

Sorry for my bad terminology. By reset I mean to tell PL to not use a CPU core and use it again, in other words to 'flick it off then back on'. Concerning Splintercell Blacklist, after reloading from a checkpoint while in game CPU core 0 (I have 4 logical cores) shoots up to 100% usage while cores 1, 2 and 3 are behaving normally. So I was wondering if there was any way in PL to script a rule or something to similar effect.

Jeremy Collake · October 12, 2014, 07:08:09 AM

Yes, there is. You can use the Watchdog rules (see Options menu) to some effect. There are caveats though. See above post.

I'm continuing to improve the watchdog rules and in some future version you should be able to better accomplish what you desire. It's hard to cover all conceivable scenarios, but I'm getting there!

AussiePatriot · October 12, 2014, 08:53:10 AM

Hi Jeremy,

Yes I have been fiddling with the watchdog rules and I can tell PL to not use Core 0 when the total CPU load(%) reaches 60%. But the watchdog rules seems to only allow you to create 1 rule per process(?) Is that right? If only I had the option to to create said rule on a 'per core' basis, and more then 1 rule per process.

Jeremy Collake · October 12, 2014, 09:11:52 AM

In the latest version (7.0.2.4, released yesterday), you should be able to create more than one rule per process. If you run into any troubles, let me know and I'll resolve them, and extend the code if necessary.

AussiePatriot · October 12, 2014, 09:52:49 AM

Hi again,

Just want to say I really appreciate the effort you've put into this tool.

Yep I can now apply 2 rules under watchdog options, but it seems still that the rule will only apply once, but what I need is it to always be in an infinite loop between the 2 rules. Is that the case with watchdog rules, that each rule will only apply once?

Also though, I believe that what I would like to achieve would be much easier if I could apply a watchdog rule to set afinity based on an individual core. That would solve my problem, and to have the 2 rules in a loop as I mentioned above.

Jeremy Collake · October 12, 2014, 10:18:43 AM

Hmm, I will check this out and make sure it works as intended. It is supposed to continually reapply the rules.

BenYeeHua · October 12, 2014, 10:47:37 AM

So, I guess this topic is asking for a way to reapply, change the CPU affinity of a processes again and again(maybe each 1 min), so it will always force to use all core for all threads, instead of the threads is locked to 1 CPU/core only, and causing lag because of the core 0 is getting 100% cpu load.

Jeremy Collake · October 13, 2014, 10:24:13 AM

The actual cause is a protection added to prevent certain rules from going haywire and repeating indefinitely.

Therefore, the fix is to the core design of the watchdog system. It was always intended to work in a way that facilitates the scenario described here, but later changed to protect against more bizarre sets of rules.

I will release a new beta with this fix some time this week. It will need a good amount of testing since this is the core code, not simply a UI bug.

Bear with me, again, and I'll get this working exactly as you need --- something I'm doing not so much for you as for all users, and myself.

Jeremy Collake · October 14, 2014, 01:00:28 PM

I am issuing a new beta v7.0.1.7 in a few minutes.

This build may be the first where the rules you desire here work correctly. In prior builds, they'd only be applied once per instance of the target process(es).

Now, they will repeatedly be reapplied whenever the process exceeds the threshold.

Development in on-going though.

AussiePatriot · October 14, 2014, 09:11:16 PM

I salute you sir,

Haven't had a chance to check it yet but I will tonight after work.

Jeremy Collake · October 14, 2014, 10:25:49 PM

Quote from: AussiePatriot on October 14, 2014, 09:11:16 PM
I salute you sir,

Haven't had a chance to check it yet but I will tonight after work.

It is still experimental, so take your time in testing it.

Thanks!

AussiePatriot · October 19, 2014, 12:01:15 PM

Sorry for the late reply. I'm typing this from my phone at work.

I've had 2 sessions now testing the latest beta. I have configured 2 watchdog rules such as the following:

1, when (total) CPU load greater then 64% for 1 second set affinity to 1-3 (I have 4 logical cores)
2, when (total) CPU load is greater then 5% for 1 second set afinity to 0-3.

The reason I choose 64% is because when core 0 spikes after a reload in-game (splinter cell) the game will hover around 64% total CPU load while I have core 0 spiking. So as you know I simply want core 0 to switch off then back on to make it behave normal again.

The first time I tried I only had a quick play around several days ago. It seemed to be applying the rules correctly.

But earlier this evening after further testing it will still apply the rules I've created but sporadically. Sometimes the second rule to change afinity back to all cores doesn't kick in after 1 second as I stated, it seems to get confused still.

One further thing I'd like to mention is, how difficult would it be to add code to allow the existing watchdog rules to a 'per core' as this would be much more accurate and efficient way to solve this problem by being able to apply these rules to a particular core (in my case core 0)

Biiiiiig thx in advance!

Jeremy Collake · October 19, 2014, 01:31:24 PM

The per-core utilization metric is coming in this next beta series, which I'll start publishing very soon.

I will play around with this scenario a bit, review your experiences, and see what improvements need to be made. There are some big changes to the entire watchdog system that I'm looking to make. They will make it much more robust and reliable.

edkiefer · October 19, 2014, 01:39:47 PM

Quote from: AussiePatriot on October 19, 2014, 12:01:15 PM
Sorry for the late reply. I'm typing this from my phone at work.

I've had 2 sessions now testing the latest beta. I have configured 2 watchdog rules such as the following:

1, when (total) CPU load greater then 64% for 1 second set affinity to 1-3 (I have 4 logical cores)
2, when (total) CPU load is greater then 5% for 1 second set afinity to 0-3.

The reason I choose 64% is because when core 0 spikes after a reload in-game (splinter cell) the game will hover around 64% total CPU load while I have core 0 spiking. So as you know I simply want core 0 to switch off then back on to make it behave normal again.

The first time I tried I only had a quick play around several days ago. It seemed to be applying the rules correctly.

But earlier this evening after further testing it will still apply the rules I've created but sporadically. Sometimes the second rule to change afinity back to all cores doesn't kick in after 1 second as I stated, it seems to get confused still.

One further thing I'd like to mention is, how difficult would it be to add code to allow the existing watchdog rules to a 'per core' as this would be much more accurate and efficient way to solve this problem by being able to apply these rules to a particular core (in my case core 0)

Biiiiiig thx in advance!

I am little confused, it looks like conflict there , mean both rules can try to apply when 64+ cpu% .
I would use "less than " rule on second one like this .

1, when (total) CPU load greater then 64% for 1 second set affinity to 1-3 (I have 4 logical cores)
2, when (total) CPU load is less than 50% for 1 second set afinity to 0-3.

You can set second value to your needs , While I never use watchdog , the above makes sense to me , see what support says .

AussiePatriot · November 05, 2014, 01:05:01 AM

Hi Jeremy,

Sorry for the longest time since my last reply, Have been busy with work and a touch of cold and covering shifts at work from others taking sickies aswell... grrr... But I'm back now. So I was just wondering about that I remember I read somewhere that you were going to implement some new watchdog rules on a per core basis? When might we see these new changes?

BenYeeHua · November 05, 2014, 10:35:55 AM

When it is done.

Just kidding, as coding depend on many factors, so we can't always know when we might see it.

Jeremy Collake · November 05, 2014, 10:57:57 AM

It won't be long. I don't want to give a specific date, but it is coming.

AussiePatriot · December 03, 2014, 04:59:20 AM

Hi Jeremy, whats the latest?

Jeremy Collake · December 03, 2014, 11:16:14 AM

Wow, I can't believe it's been a month since I posted in this thread.

I've got a new final version I'm publishing within the next couple days, then will begin a new beta series where I'll try to move the marker here.

However, I have some design concerns, part of the reason for the delay. The initial implementation will be based on simple division and won't be a true per-core measure, though will probably be fine for your purposes.

For instance, if you specify a rule that acts on 100% per-core for a 4 core system, it will get divided by 4 to equal 25% total CPU consumption. However, that 25% could be spread across multiple cores, instead of a single core fully utilized.

You could do the same math manually in the current version. Just divide any CPU % by the number of cores you have.

Long-term, I continue to look towards rewriting the watchdog mechanism. One week this will suddenly just start happening, as soon as I have the design mapped out. This will solve any other continued issues and make the whole system much more robust and reliable. The current implementation grew organically over time and just isn't right for heavy duty lifting.