CPU C0 below 100%, but no higher C state registered?

Another 2 hours running idle via Balanced Power plan while HWinfo kept running, switched to Ultimate power plan with Idle disabled, opened Steam, Discord and Edge. Still no problem with Defender resetting the counters. So indeed it seems like setting counter 0 might help HWinfo.

1711986180988.png
 
Thanks for the feedback. Even though I don't like this solution, it seems there's no alternative, so I will keep this in future builds.
 
The 3:13 hours I posted earlier were screenshot after using the "Reset Counters" button of the Counter Control app (3:13h before the screenshot). This is still working with the new HWinfo build.

1711992418458.png
 
Unfortunately that one works even less. HWinfo tries to reset to 0x332 instead of 0x330, though. So maybe including counter 0 would help?
 
"Worse" might be badly worded. Instead of displaying an average between Defender and HWinfo it now jump between full clock/C0 and zero, which is kind of a better reading for the non-zero part. But at 2 seconds default polling period it just stays at all zero.
 
Well, that was an attempt with resetting counters. But it seems neither this has an effect on Defender..
Now I'm lost, no idea what else to try...
 
Could you try to reset to 0x330 instead of 0x332, aka did you leave out counter 0 in your reset? I also noticed that resetting via Counter Control takes 3 seconds before the button becomes usable again, so it either is rather busy or it just doesn't want the user to spam the button to fast!?
 
Sorry, I don't think that combining both will make a difference.
Maybe TS does reset the counters for all cores in multiple loops to somehow trick Defender into believing they don't work, so it won't use them.

Moreover, it's interesting why Defender sets the counters to measure only kernel occupancy (CPL=0). Maybe there's a reason for this - the realtime protection checks if specific processes execute also tasks in kernel. So disabling this feature might reduce its capability to detect some threats...
 
The "Reset Counters" button does not spawn an extra thread when it's pushed, though, the whole Counter Control process runs on a single thread with a short load increase from 20-25 mio. cycles delta to 37-40something cycles delta (so basically nothing). The difference is that afterwards it says "Normal" 0x330, whereas the last HWinfo build reverted back to 0x332.
 
0x332 should be normal as well IMO. What matters are only counters 1-2 which are the higher nibbles - 0x33x.
0x33x is our desired state, important is that it doesn't switch back to 0x22x
 
Hwinfo runs the counters in 0x330 as long as Defender doesn't fight back. Once Defender pushes its own 0x222 the result is that the counters keep switching between 0x222 and 0x332. Once Counter Control's "Reset Counters" button is used the counters revert back to the same 0x330 HWinfo originally pushed and then stay there even with Defender being active. This does suggest that Defender might needs exactly that reset to 0x330 to stop its own thing.

You might be right that Defender does this for a reason, but then again it also stops its own counter messing, so how important the whole thing is for full protection remains unknown. Personally I am fine with knowing how to manually get Defender out of the way, now that I have more information about the problem and its workarounds.
 
And even though the behavior of the last build looks rather odd, at least it makes it obvious to users that something is getting in the way of the measurement. Before that it wasn't really visible unless you specifically enforced "Disable Idle" (which many people don't even know about).

1712011948794.png
 
Danke für die Mühe! It was worth a try. Unfortunately still switching back and forth between both counter settings. So it seems like Kevin Glynn has another trick up his sleeve to make this stick for Counter Control and Throttlestop. Still good enough for me personally, but obviously this makes HWinfo measurements rather unreliable with Defender being active.

1712052563494.png
 
You must log in or register to reply here.
Back
Top