Effective clock speed

[unclewebb]

mV Boost value isn´t applied

The mV Boost feature works correctly on my 10850K. This might not work correctly or at all on 10th or 11th Gen mobile H series CPUs. In theory, this setting should be locked out if the CPU does not support it. Based on user feedback so far, I do not think any of the H series CPUs support mV Boost.

The problem this feature tries to solve is that you might be able to get away with a big undervolt when a CPU runs at full speed but this same undervolt can cause a BSOD when the CPU is lightly loaded. I thought being able to boost the voltage curve a little at low frequencies might help the cause. When I originally added mV Boost, I did not realize that the H series do not seem to allow this level of control. This experimental feature might be removed in the future if I ever find something to put in its place.

On 9.4.2 the reported value changes accordingly to the power plan.

Newer CPUs have two separate Speed Shift EPP registers. I do not have access to anything newer than my 10th Gen desktop CPU so trying to get this feature working correctly for both old and new CPUs has been a challenge. If you check the Speed Shift EPP box on the main screen, can you adjust the EPP value here and does the requested EPP value show up in the FIVR monitoring table? If this works then I will probably leave this as is.

any core voltage value set in adaptive mode isn´t applied

I always move the Voltage slider all the way to the left and set this to Default when I am using Adaptive mode. I am not sure if any Intel CPUs allow one to set a voltage value when in Adaptive mode. ThrottleStop correctly sends this request to the CPU but if the CPU does not understand the request, it simply ignores it. Without access to a wide variety of hardware, I tend to leave things like this unlocked so users can experiment. If something does not work, do not use it.

the Non Turbo Ratio option inside the FIVR window is greyed out.

Newer CPUs do not use the Non Turbo Ratio for CPU speed control when Speed Shift is enabled. That is why the Non Turbo Ratio setting is now greyed out.

the Extra Turbo Voltage option is greyed out

I think the Extra Turbo Voltage feature only applies to the 2nd and 3rd Gen CPUs. That is why this setting is greyed out on newer CPUs.

 

[ivanosky]

Hi @unclewebb, I can confirm that newer Throttlestop versions always show a 128 Speed Shift EPP value on the FIVR window on an Intel 11800H in Windows 11. I was previously using TS 9.4, and it was showing different EPP values when changing the Balanced Power Plan options in the Power Settings (84 for Balanced, 63 for Best Performance, 128 for best Power Efficiency).
But today after updating TS to 9.5 to use the new Windows Defender Boost feature, the EPP value is always 128 on the FIVR window.
Activating the Speed Shift checkbox on the main window and changing the EPP value makes the FIVR window show the value entered in the main window.

 

[TwistedAndy]

I'm doing some research around the mV Boost option. It looks to be working on 12900HK. Unfortunately, stability on the low power limits is harder to test.

 

[i7core]

@unclewebb
Did you manage to figure this out?

 

[sirAIfred]

It's possible that ThrottleStop made some changes to the CPU's voltage and frequency settings that improved its performance. When you started ThrottleStop, did you notice any changes to the CPU's voltage or frequency settings?

If not, you can try using the program's monitoring tools to see if there are any differences in the CPU's behavior between when ThrottleStop is running and when it's not.

You can also check the log file generated by ThrottleStop to see if it made any changes to the CPU's settings. To do this, open ThrottleStop and click on the "Options" button at the bottom of the main window. In the options menu, click on the "Logging" tab and make sure that the "Log File" option is enabled. Then run your test and let ThrottleStop run in the background for a while. When you're done, close ThrottleStop and navigate to the log file location (specified in the options menu). Open the log file in a text editor and look for any changes made to the CPU's settings while ThrottleStop was running.

If you're still not sure what changes ThrottleStop made to your system, you can try contacting the program's developer, UncleWebb, for more information. He is very responsive and helpful, and may be able to provide more insight into what happened.

 

[unclewebb]

Did you manage to figure this out?

Some CPUs use two separate Speed Shift registers. My 10850K only uses one register for CPU control.

Without access to a variety of newer hardware, I have decided to leave Speed Shift as is. There is no point in making random changes without being able to properly test the results on both old and new hardware.

 

[i7core]

It's possible that ThrottleStop made some changes to the CPU's voltage and frequency settings that improved its performance. When you started ThrottleStop, did you notice any changes to the CPU's voltage or frequency settings?

If not, you can try using the program's monitoring tools to see if there are any differences in the CPU's behavior between when ThrottleStop is running and when it's not.

You can also check the log file generated by ThrottleStop to see if it made any changes to the CPU's settings. To do this, open ThrottleStop and click on the "Options" button at the bottom of the main window. In the options menu, click on the "Logging" tab and make sure that the "Log File" option is enabled. Then run your test and let ThrottleStop run in the background for a while. When you're done, close ThrottleStop and navigate to the log file location (specified in the options menu). Open the log file in a text editor and look for any changes made to the CPU's settings while ThrottleStop was running.

If you're still not sure what changes ThrottleStop made to your system, you can try contacting the program's developer, UncleWebb, for more information. He is very responsive and helpful, and may be able to provide more insight into what happened.

Okay, will try the log-file. The voltages/frequency look the same with/without ThrottleStop.

Some CPUs use two separate Speed Shift registers. My 10850K only uses one register for CPU control.

Without access to a variety of newer hardware, I have decided to leave Speed Shift as is. There is no point in making random changes without being able to properly test the results on both old and new hardware.

So the 8700K uses two registers? I have tried to solve this with many combinations in the BIOS (C-state, Speed Shift, etc.), but won't work without the ThrottleStop.

 

[unclewebb]

8700K

I thought you were talking about an 11th Gen or newer processor. What problem are you trying to solve? Be very specific. Show me some screenshots so I do not have to guess.

won't work without the ThrottleStop

If ThrottleStop can solve your problem then I do not understand what you are asking. Perhaps the BIOS or Windows is not setting your CPU up correctly. That happens. Are you using Windows 10 or Windows 11?

I prefer enabling Speed Shift in the BIOS. If this was not enabled when you first installed Windows then that might be a problem. Windows 11 seems to assume that all 8th Gen and newer Intel CPUs have Speed Shift enabled.

 

[Deleted member 185158]

Okay, will try the log-file. The voltages/frequency look the same with/without ThrottleStop.


So the 8700K uses two registers? I have tried to solve this with many combinations in the BIOS (C-state, Speed Shift, etc.), but won't work without the ThrottleStop.

Try a different cpu multiplier. Like 46 or 48. Only thing to disable is c-states in bios if you don't want the system to throttle (save power). All the boost stuff turns off when you manually clock these, however the conflict sometimes happens when using the boost multiplier. Not sure why, just a hunch , something I've experienced. Both on 8th and 12/13th gen.

It also shouldn't matter if windows is in performance mode or not when manually overclocking. C-states is the only feature to be active when setting a manual cpu multiplier. On, cpu throttles, disabled, cpu should hold the clocks no matter what.

 

[i7core]

I thought you were talking about an 11th Gen or newer processor. What problem are you trying to solve? Be very specific. Show me some screenshots so I do not have to guess.


If ThrottleStop can solve your problem then I do not understand what you are asking. Perhaps the BIOS or Windows is not setting your CPU up correctly. That happens. Are you using Windows 10 or Windows 11?

I prefer enabling Speed Shift in the BIOS. If this was not enabled when you first installed Windows then that might be a problem. Windows 11 seems to assume that all 8th Gen and newer Intel CPUs have Speed Shift enabled.

I'm referring to my initial post in this thread - didn't think it would be necessary to re-write it.

But I guess you are right, something is probably messed up with either BIOS or Windows (10). I could enable Speed Shift (at the moment on "Auto") in BIOS and re-install Windows to try that out, but to lazy for that now. ThrottleStop 9.3 solves this as earlier mentioned and will do for now.

Try a different cpu multiplier. Like 46 or 48. Only thing to disable is c-states in bios if you don't want the system to throttle (save power). All the boost stuff turns off when you manually clock these, however the conflict sometimes happens when using the boost multiplier. Not sure why, just a hunch , something I've experienced. Both on 8th and 12/13th gen.

It also shouldn't matter if windows is in performance mode or not when manually overclocking. C-states is the only feature to be active when setting a manual cpu multiplier. On, cpu throttles, disabled, cpu should hold the clocks no matter what.

Just tried with 46x and C-states disabled - no luck unfortunately.

 

[unclewebb]

I'm referring to my initial post in this thread

The effective clock mystery was finally solved. It was hard to remember what you were talking about. A lot of problems have come and gone since you originally asked this question last March.

The effective clock dropping at random times and staying lower than normal was being caused by Windows Defender.

Here is some background info. Many of the timers within Intel CPUs are a shared resource. That means any software can re-program these monitoring timers for any purpose. You can end up with a situation where two different programs have programmed the same timer to different values. This would be like two different people both trying to use the same stop watch to monitor and time two different events. The results would be unpredictable. Windows Defender was re-programming one of the system timers. HWiNFO and most other monitoring apps usually share this timer without any issues. Windows Defender was a bit of a bully. When Defender started using this system timer, HWiNFO was no longer able to measure and report the effective clock speed accurately.

At the same time that this starts happening, Windows Defender would start up a separate process that would significantly load one of the CPU cores or threads. I am still not sure what Defender was doing with all of the CPU cycles that it was using. Windows Defender does not seem to have this problem when running on newer 12th and 13th Gen CPUs. Whatever Defender is doing only seems to be happening on 8th Gen through 11th Gen CPUs. Perhaps slightly older CPUs too like 6th or 7th Gen. It was not happening on the 4th Gen CPU I tested.

ThrottleStop 9.3 used to use one of the system timers. When Defender saw that this timer was in use by ThrottleStop, Defender would never start up its secret algorithm in the background. That is why you used to get maximum performance when running ThrottleStop 9.3. No wasted CPU cycles by Windows Defender.

ThrottleStop 9.4 stopped using this system timer because it no longer needed to use this timer. With Intel timers being a shared resource, I thought using less of them would be a good thing to do. When Defender determined that this timer was not in use, it would start up its CPU using / abusing algorithm in the background.

Some people assume that whatever Windows Defender is doing must be important. I disagree. If the code it runs on an 8th Gen CPU is important, why does it not need to run this code on newer CPUs? Why does this important algorithm not get started for the first 5 minutes after Windows boots up? If the code it runs is that important, it should be running all of the time on all CPUs.

I decided to add a new feature to ThrottleStop 9.5 to help manage Windows Defender.

In the Options window is a new feature called Windows Defender Boost. When this box is checked, ThrottleStop 9.5 will start up the system timer that it used to use in older versions of ThrottleStop. This is enough to prevent Windows Defender from excessively hogging too many CPU cycles. ThrottleStop does not need to use this timer anymore but starting it and letting it run quietly in the background is an easy way to fix whatever Windows Defender is doing. The effective clock no longer decreases when this box is checked and you also get maximum performance because Defender is no longer wasting 5% or 6% of your CPU performance. Laptops get better battery runtime without the wasted CPU cycles.

I wrote a separate program called Counter Control that lets you have a closer look at what timers are being used by the CPU. It helped me better understand what was going on. The fix was integrated into ThrottleStop 9.5 but Counter Control is still available if you are interested in doing some testing.

https://www.techpowerup.com/download/counter-control/

If you boot up and you do not run ThrottleStop, you can watch Counter Control to see what is happening to the system timers. It was usually about 5 minutes after first booting up that Windows Defender would start gobbling up CPU cycles and this would never end. The same would happen after a sleep or hibernate resume cycle.

Some users reported that this Windows Defender bug / feature was fixed. If you are still noticing this problem then I assume that Defender never got fixed.

 

[i7core]

The effective clock mystery was finally solved. It was hard to remember what you were talking about. A lot of problems have come and gone since you originally asked this question last March.

The effective clock dropping at random times and staying lower than normal was being caused by Windows Defender.

Here is some background info. Many of the timers within Intel CPUs are a shared resource. That means any software can re-program these monitoring timers for any purpose. You can end up with a situation where two different programs have programmed the same timer to different values. This would be like two different people both trying to use the same stop watch to monitor and time two different events. The results would be unpredictable. Windows Defender was re-programming one of the system timers. HWiNFO and most other monitoring apps usually share this timer without any issues. Windows Defender was a bit of a bully. When Defender started using this system timer, HWiNFO was no longer able to measure and report the effective clock speed accurately.

At the same time that this starts happening, Windows Defender would start up a separate process that would significantly load one of the CPU cores or threads. I am still not sure what Defender was doing with all of the CPU cycles that it was using. Windows Defender does not seem to have this problem when running on newer 12th and 13th Gen CPUs. Whatever Defender is doing only seems to be happening on 8th Gen through 11th Gen CPUs. Perhaps slightly older CPUs too like 6th or 7th Gen. It was not happening on the 4th Gen CPU I tested.

ThrottleStop 9.3 used to use one of the system timers. When Defender saw that this timer was in use by ThrottleStop, Defender would never start up its secret algorithm in the background. That is why you used to get maximum performance when running ThrottleStop 9.3. No wasted CPU cycles by Windows Defender.

ThrottleStop 9.4 stopped using this system timer because it no longer needed to use this timer. With Intel timers being a shared resource, I thought using less of them would be a good thing to do. When Defender determined that this timer was not in use, it would start up its CPU using / abusing algorithm in the background.

Some people assume that whatever Windows Defender is doing must be important. I disagree. If the code it runs on an 8th Gen CPU is important, why does it not need to run this code on newer CPUs? Why does this important algorithm not get started for the first 5 minutes after Windows boots up? If the code it runs is that important, it should be running all of the time on all CPUs.

I decided to add a new feature to ThrottleStop 9.5 to help manage Windows Defender.

View attachment 288480

In the Options window is a new feature called Windows Defender Boost. When this box is checked, ThrottleStop 9.5 will start up the system timer that it used to use in older versions of ThrottleStop. This is enough to prevent Windows Defender from excessively hogging too many CPU cycles. ThrottleStop does not need to use this timer anymore but starting it and letting it run quietly in the background is an easy way to fix whatever Windows Defender is doing. The effective clock no longer decreases when this box is checked and you also get maximum performance because Defender is no longer wasting 5% or 6% of your CPU performance. Laptops get better battery runtime without the wasted CPU cycles.

I wrote a separate program called Counter Control that lets you have a closer look at what timers are being used by the CPU. It helped me better understand what was going on. The fix was integrated into ThrottleStop 9.5 but Counter Control is still available if you are interested in doing some testing.

https://www.techpowerup.com/download/counter-control/

If you boot up and you do not run ThrottleStop, you can watch Counter Control to see what is happening to the system timers. It was usually about 5 minutes after first booting up that Windows Defender would start gobbling up CPU cycles and this would never end. The same would happen after a sleep or hibernate resume cycle.

Some users reported that this Windows Defender bug / feature was fixed. If you are still noticing this problem then I assume that Defender never got fixed.

Thank you for the thorough explanation. Will try Counter Control out of curiosity - could be handy in other situations as well.