Search results

"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.

Unfortunately that one works even less. HWinfo tries to reset to 0x332 instead of 0x330, though. So maybe including counter 0 would help?

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.

The new build sets 0x330, but still fights back and forth with Defender.

Sorry, that wasn't your build yet. I didn't see your post before I posted mine. Will test the build now.

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.

50 minutes later the counters still are left untouched by Defender. So maybe HWinfo should set all three counters just once at program start to tell Defender to leave it alone? Is there a performance tax for resetting these counters every polling period instead of just once?

Here you can see HWinfo and Defender battling it out every second until I hit the "Reset Counters" button just *once*. 8 minutes later the counters still didn't switch anymore.

Using the "Reset Counters" button in Counter Control also stops Defender from changing the counter for prolonged time even in a situation where Defender and HWinfo were battling for the counter ongoingly just seconds ago.

What strikes me odd is that I did not see this happen on my former Windows 11 installation. I remembered wrong about it being an "upgrade" from W10, it was a clean installation, but it was originally installed on an AMD 5900X and then just moved over to the Intel 13900K. So whatever Windows set...

I will watch this a bit using the Counter Control application. Disabling "Windows Defender Boost" would indeed lead to TS only keeping Defender in check for a few seconds to minutes, but still not quickly fluctuating within milliseconds as with HWinfo's battle vs. Defender. In the Readme of...

And for Throttlestop it is enough to load the initial warning popup (when no configuration file exists yet), even when TS uses no single CPU cycle afterwards anymore and also when TS is stopped altogether (process killed). So whatever TS (and disabling Realtime Protection) does, it does not have...

TS fixes the problem just by starting and stopping TS, so it is not a thing of constantly reapplying the counters in quick succession. Both TS and turning Realtime Protection off->on fix the issue for prolonged time without constantly having to reconfigure values like HWinfo does, but I think...

Here is another one with Throttlestop "fixing" the issue instead of switching Realtime Protection.

Disabling and then re-enabling Realtime Protection also seems to fix the counters over prolonged times, including a sign out + relogin. Even switching power plans for a short time seems to work then, but at some point it reverts back to the bugged behavior. Unfortunately I could not reproduce...

Will do in a few minutes. I am currently checking how Defender affects this. At this moment I am in a state where switching Realtime Protection on only drops Effective Clocks + C0 readings for one HWinfo poll (2 seconds) and then everything gets back to normal. I did *not* change any Defender...

Thottlestop fixes this as soon as it is loaded, even just at the first warning popup stage. It then stays fixed without TS being loaded until the next restart (or maybe for some prolonged time, have to test) even over a relogin and power plan switching.

Can anyone explain this behavior? This happens after setting a power plan's "Processor Idle disable" to "Disable Idle". This should disable all C-states other than C0 and run all cores at maximum all-core boost ratios, including Effective Clocks. It happens on a new installation of Windows 11...

I compared average CPU Package Power at 100 ms and 1000 ms polling rate, running the same reproducible load (Handbrake encode). They match close enough, so I assume that the CPU power counter and time-delta likely are trustworthy while throttling isn't instant enough to keep power from increase...

My settings are PL1 = PL2 = 253 W. So the default Tau of 56s is essentially unused, except for changing the trigger sensor from PL2 to PL1 after some time.