How is CPU frequency calculated?

[Haswellx86]

Using AI I got an overview of how Turbostat calculates CPU frequency on Linux which involves the TSC_MHz clock, APERF and MPERF registers and all. I think i7z also calculates in a similar way. But the problem is that all sources of reporting CPU clock frequency from hardware (software reporting is out the window) report in some variation. That variation is small, and if I change the clock frequency by a big amount like 100 MHz or lock it, that does reflect from all the sources, but still it is kind of bothering me in which source to believe in what my CPU is actually running at. The variation is likely caused due to different measurement timings of each program.

 

On this machine, which boosts to 3.6 GHz, in 100% C0 state, i7z reports the frequency being 3591 MHz (is it me or this value feels more satisfying?) whereas Turbostat reports a plane 3600 MHz across all threads. When the CPU is idling, Turbostat's reading isn't locked to 3600 MHz and does fluctuate like i7z as well, but Turbostat's reading is always a bit higher and reaches 3600 MHz whereas i7z never reaches that value. I kind of thought to believe i7z more because it takes in account of Hyperthreading, reports the multiplier and reports the highest frequency of all the cores as the current frequency. But then also it is a very old program and discontinued (but still works) and it thinks my Coffee Lake system is Nehalem and my Comet Lake system as Haswell. But then Turbostat is still also aware of these and actually comes with the official Linux source itself, but not to say that it is the most reliable way because it sometimes reports above 3600 MHz.

 

If I lock my frequency to 3 GHz, i7z still reports like 2991 MHz with small variations whereas Turbostat reports 3000 MHz. If i7z is reporting some fluctuation, I do see some fluctuation on Turbostat as well, but the values there are generally higher.

 

I tried to test HWInfo on my other machine (for some reason I think I should believe HWInfo the most) running Windows which boosts to 4.2 GHz (it mostly boosts to 4.1, maybe because of Intel TVB), and HWInfo reports just like i7z. It reports the frequency being like 4091, 3891, etc. Note that i7z and HWinfo don't just report in xx91 values, they do report other values as well but most of the time, especially when the CPU is fully active, they report in such format. Throttlestop mostly reports something like 4150 which is just different from all (probably averaging or something as it ).

 

On my Linux system I disabled turbo and I got like 1691 (fluctuating a bit) from i7z and similar from Turbostat but it would go upwards to 1700. On my Windows machine, I disabled Turbo and from both HWInfo and Throttlestop, I got a locked 1596 MHz (I know they are different CPUs though). I also tried CPU Z on my Windows machine and it's output was very similar to that of HWInfo.

 

So upon all of this, I have a few questions -

a) Is the actual CPU frequency is able to be different across all cores, or are they always same and in sync (pretty sure different but just clarifying)? On my system I have tried a lot to set one core to a different speed than the others, but I just couldn't. On a more unlocked system, is it possible to set different clock speeds for individual cores?

 

b) Why does CPU clock frequency keep changing so fast? Why is it never stable? I think you can make it fully locked in UEFI so it's just the automatic scaling I guess, but why does it keep changing?

 

c) What source should I believe? If my CPU boosts a max of 3.6 GHZ on paper, is it running at 3589, 3590 and 3591 MHZ or 3600 MHz? If it is locked at 3 GHz (so frequency is more stable), is it running at 2991 MHz or actually 3000 MHz? I know a 9 MHz difference is nothing, but as I said, it just want to know the correct value.

[porina]

2 minutes ago, Haswellx86 said:

b) Why does CPU clock frequency keep changing so fast? Why is it never stable? I think you can make it fully locked in UEFI so it's just the automatic scaling I guess, but why does it keep changing?

Power saving, which could allow cores that are active to have more power and run faster. If a core isn't doing anything, it can do nothing slower. Different code can also have different power profiles, which means the boost clock can vary due to that.

 

2 minutes ago, Haswellx86 said:

c) What source should I believe? If my CPU boosts a max of 3.6 GHZ on paper, is it running at 3589, 3590 and 3591 MHZ or 3600 MHz? If it is locked at 3 GHz (so frequency is more stable), is it running at 2991 MHz or actually 3000 MHz? I know a 9 MHz difference is nothing, but as I said, it just want to know the correct value.

At a basic level, running clock is bus (reference) clock multiplied by multiplier. If the bus isn't exactly 100.0000 MHz, you will see the clock scale accordingly. Nowadays it feels like most boards run at or ever so slightly below 100 MHz, leaning towards stability. In the old days, they'd push up to 103 MHz to get that tiny advantage in  benchmarks at the cost of reduced stability. Note spread spectrum is also a thing now, to try and reduce the strength of emissions at a certain frequency. That does it by varying the clock, so would also need to be accounted for if enabled.

 

The other part is, how accurate is the measurement? Some measurement error isn't out of the question so I wouldn't worry about it.

[Haswellx86]

@porina

 

Yes, my bus clock isn't exactly 100 MHz. In i7z I see it changes between 99.74 and 99.79. If I do the math, 99.74 and 99.79 times 36 is 3592 and 3590 which explains the frequency i7z reports. Also i7z reports the multiplier as a decimal and most of the time it is below 36 (very high 35's).

 

So does that mean the 3600 MHz peak clock speed is in account of a 100 MHz bus clock? Does that mean i7z is right in that I generally run 9 MHz lower? And so is Turbostat really actually wrong (it definitely also uses the current bus clock so could be a measuring difference)?

[porina]

6 minutes ago, Haswellx86 said:

Also i7z reports the multiplier as a decimal and most of the time it is below 36 (very high 35's).

I'm not familiar with that software. Some might report some kind of average as opposed to instantaneous, which of course would be changing continuously so at best would be a snapshot.

 

Depending on the CPU there are fractional multipliers. AMD CPUs go in nominally 25 MHz steps. I hear newer Intel CPUs might go even finer than that, but I don't have experience of one.

 

6 minutes ago, Haswellx86 said:

So does that mean the 3600 MHz peak clock speed is in account of a 100 MHz bus clock?

Officially listed clock speeds will be at nominal clock so any deviation from that will shift it up or down accordingly. I'm not familiar with either of those software to comment further on them.

[unclewebb]

@Haswellx86

 

The BCLK speed tends to be a lot more stable than what most monitoring software will show you. The BCLK speed hardly varies at all when properly measured. The crystal oscillators that generate the clock speed have only a tiny percentage of error. When you see software reporting the BCLK speed varying all over the place, that is usually just monitoring error that you are seeing.    

 

When using Windows, try running ThrottleStop. Press the FID button at the top left of the monitoring table multiple times. Each time you press this button, ThrottleStop will recalculate the BCLK speed. My Asus Z490 motherboard is set to run the BCLK at a true 100.0000 MHz. Many motherboards will run the BCLK at a speed slightly less than this. Somewhere close to 99.77 MHz seems to be common. My MSI laptop with a 14900HX defaults to a steady 99.777 MHz. 

 

 

[Haswellx86]

@unclewebb

 

So if you are running a true 100 MHz BCLK, and if multipliers are whole numbers, do you always run at a nice 100 x multiplier frequency? I see from your screenshot that you are running at a clean 5000 MHz that too locked.

 

Why is it locked though? Did you lock the multiplier? The FID did go to 4.99 for 2 threads.

 

1 hour ago, porina said:

Officially listed clock speeds will be at nominal clock so any deviation from that will shift it up or down accordingly.

If Intel states my CPU turbos up to 3.6 GHz, how do they account in the base clock? I assume they just take 100 MHz and anyways BCLK only varies under a megahertz so that doesn't make any significant difference at all.

 

So keeping the software reporting aside, does that mean my CPU cannot possibly run at 3600 MHz due to the BCLK being lower? And what about the in-between frequencies? For that the CPU multiplier has to be fractional right? Or else you would only go up and down by 100 MHz (or whatever your BCLK is).

[unclewebb]

59 minutes ago, Haswellx86 said:

The FID did go to 49.99 for 2 threads.

You are looking for perfection in an imperfect world. When a CPU is idle, cores and individual threads are always going to be bouncing around into and out of various low power C states. This can interfere with getting perfect results, but even so, the accuracy of the multiplier that ThrottleStop reports when a CPU is idle is second to none. 

 

When you fully load a CPU so the cores and threads are spending all of their time in the active C0 state and none of their time in any of the low power C states, then the multiplier accuracy that ThrottleStop reports starts approaching the perfection that you are looking for. This example shows that when running a full load 20 thread TS Bench test, all cores and all threads are individually reporting the exact same 50.00 multiplier. 

 

 

HWiNFO and CPU-Z are not accurate whenever a CPU starts thermal throttling or power limit throttling. In these situations the multiplier can start varying hundreds of times per second. ThrottleStop uses high performance monitoring timers within the CPU and closely follows the Intel recommended monitoring method. ThrottleStop has no problem accurately reporting the average CPU speed when throttling is in progress. The method that most popular monitoring software uses is nowhere near as accurate. 

 

 

59 minutes ago, Haswellx86 said:

 

Why is it locked though?

If you use the Windows High Performance power plan and all of the turbo ratios or turbo groups are set to the same value, the CPU will run at a constant speed as long as the low power C states are not interfering with that. In my first example that I posted, core C7 was enabled. That C state generally does not cause any monitoring issues. C1E was disabled. When C1E is enabled and C7 is disabled, the reported multiplier for each thread will start jumping up and down wildly depending on what percentage of time each thread is spending in the C1E state. The C state demotion and undemotion options can also impact multiplier reporting when a CPU is idle. 

[Haswellx86]

17 minutes ago, unclewebb said:

low power C states

Ah yes, C states is the reason. That is why I get a constant 3591 in i7z when in C0 state. Does that mean when the CPU is idling and jumping in between all the C states, is it still actually running at max frequency and it's just the reporting that can't get it right and reports lower values, or is the CPU actually running at lower frequencies?

 

24 minutes ago, unclewebb said:

In these situations the multiplier can start varying hundreds of times per second.

So if we are talking physically, that doesn't happen right? My reporting tools also sometimes report quite a big differences between clocks of other cores. I asked this before that is the multiplier always set the same across all cores? Is it not possible to change the clocks of individual cores? If not, then the different core clocks across different cores in CPU monitoring softwares is just a reporting error?

[starsmine]

12 hours ago, Haswellx86 said:

Ah yes, C states is the reason. That is why I get a constant 3591 in i7z when in C0 state. Does that mean when the CPU is idling and jumping in between all the C states, is it still actually running at max frequency and it's just the reporting that can't get it right and reports lower values, or is the CPU actually running at lower frequencies?

 

So if we are talking physically, that doesn't happen right? My reporting tools also sometimes report quite a big differences between clocks of other cores. I asked this before that is the multiplier always set the same across all cores? Is it not possible to change the clocks of individual cores? If not, then the different core clocks across different cores in CPU monitoring softwares is just a reporting error?

In all modern processors, cores are clock gated from each other, many will run their own PLLs which would be letting you change the multiplier per each core. 
https://en.wikipedia.org/wiki/Phase-locked_loop

[Haswellx86]

4 hours ago, starsmine said:

In all modern processors, cores are clock gated from each other, many will run their own PLLs which would be letting you change the multiplier per each core. 
https://en.wikipedia.org/wiki/Phase-locked_loop

Okay thanks but can you tell me if it is even possible for me to hit true 3600 MHz when by BCLK is like 99.74? Because 99.74 * 36 is 3590.64. But is the multiplier even whole 36? Because in i7z it reports the multiplier in decimals. And if the multiplier is going above 36 to reach 3600.

[unclewebb]

23 hours ago, Haswellx86 said:

or is the CPU actually running at lower frequencies?

What is reported depends on what C states are being used. When an individual core enters the C7 state, it is disconnected from the internal clock and it is disconnected from the voltage rail. The core is dormant and not running at all. ( 0 MHz and 0 volts )

 

There is no way for monitoring software to report this correctly. If software needs to wake a core up to query its frequency, it will no longer be at 0 MHz. The moment the monitoring program finishes its query, the CPU core will go back into C7 and will be back at 0 MHz. 

 

When my computer with a 10850K is idle at the desktop, all 10 cores can average 99% of their time in the C7 state at 0 MHz. The other 1% of the time, cores will be active and will run at the full 5000 MHz. Monitoring software can report that the CPU is at 5000 MHz but the reality is that CPU core might not be running at any speed 99% of the time. That is why it is important to report both MHz and C state activity, especially when a CPU is lightly loaded.  

 

 

Intel Core i CPUs only use multipliers that are whole numbers. If during a 1 second monitoring interval the CPU uses the 50 multiplier for half a second and the 47 multiplier for the other half of a second then ThrottleStop will average that out, (50 + 47) / 2 = 48.50

 

That number best represents the average speed the CPU was running at. When a CPU core is spending 99% of its time in C7, this precise multiplier calculation can show a tiny amount of error. Usually less than 0.05. 

 

Intel CPUs use high performance timers that run at billions of cycles per second. These timers can be used to precisely determine the exact amount of turbo boost (multiplier). Very few Windows monitoring tools use this Intel recommended method.  

 

6 hours ago, Haswellx86 said:

is even possible for me to hit true 3600 MHz when by BCLK is like 99.74

If your BCLK does not run at 100.000 MHz and your maximum multiplier is limited to 36 then it is going to be impossible to ever run at the full 3600 MHz. Almost every computer at default settings will run the BCLK at slightly less than 100.000 MHz. The default BCLK speed is typically between 99.77 MHz and 99.78 MHz when properly calculated. That is just the way it is.

 

Some computers with advanced BIOS settings and a programmable PLL clock generator can set the BCLK speed to exactly 100.000 MHz. This feature tends to be limited to only high end motherboards. 

[Haswellx86]

@unclewebb

 

Thanks for explaining it so well! I didn't even realize C states play an actual role in clock frequency.

 

So if we get back to the main topic where I was asking which source to believe on Linux, I am pretty sure I should believe i7z and not Turbostat because Turbostat reports values like 3600 and 3000 MHz which aren't possible with a whole multiplier and my BCLK.

 

I tried cpupower and that also monitor's my frequency as 3590 in 100% C0 state like i7z (bit I will prefer i7z as it gives more stable readings and is Hyperthreading aware).

 

I went over to my Windows laptop and I guess I see what you say. I kept ThrottleStop aside because it had different result than others, probably because it is right. The frequency and the multiplier in that are much more stable, and I hope not artificially. I also put a single threaded load (I get power limited so can't put all cores in pure C0) and ThrottleStop did report around 4090 MHz and 41 * 99.767 is 4090 (It barely ever does 42, probably TVB). So at the least I can believe the 100% C0 frequencies and Turbostat is wrong. False. Torvalds should remove it from the Linux source.

 

But I still have some questions. What I noticed on my Windows laptop is that the multiplier is till not quite locked, and I am running at like highest power profile, and I even have all core turbo ratios to max. The TVB confusion aside, when idle, the multipliers are pretty stable, but still constant fluctuations in the decimals and even go 1 to 2 steps lower sometimes, but I guess that is reasonable for running in 99% C7 and the fluctuations could be due to background load, but I am not sure.

 

But whenever I put some load such as opening the start menu, I saw the frequency always drop a little and the multiplier as well. Still a C7 issue? But why doesn't this occur to you? Or does it? No kind of throttling btw.

 

What I could do is disable the deeper C states and make it run in C1 (I think it's C1) all the time. The PKG power reflects the change. This locked the frequency to 3890 MHz (39x) for some reason (Task Manager reflected this too), but I noticed that the frequency was much more stable. Whatever load I put (within throttling limits) only slightly deviated the multiplier that too very less times only. It wasn't constantly changing it's decimal places in the multiplier. It was actually locked. I don't know why the frequency was set that value (do turbo ratios have to do anything? because the default lowest is 39 but I set all of them to 42) but I think because it's running in C1, the multiplier reading is that stable. On my Linux machine too I see this behavior where i7z reports 3591 in C1 state also and in C0.

 

CPU frequency reporting is indeed complicated and Throttlestop seems to do the realistic job. It is quite underrated. I still see so many people praising to use HWInfo and CPU-Z. Sadly though, I have another problem that I use Linux and Throttlestop isn't available on it. I guess i7z will do it for now.

 

Wait..

Who are you again? And you have the TS source? Damn I didn't know we had such important people on this forum.

[unclewebb]

16 hours ago, Haswellx86 said:

Who are you again?

Busted! I try to stay under the radar but you are giving away my secrets.

 

16 hours ago, Haswellx86 said:

And you have the TS source?

If I am the guy that wrote the program then of course I have the source.  A lot of the original TS source code was actually borrowed from RealTemp. 

 

16 hours ago, Haswellx86 said:

I went over to my Windows laptop

What CPU? Most Intel mobile CPUs constantly vary the maximum CPU speed based on how many cores are active. This only works correctly if the deeper C states like core C3 or core C7 are enabled. When you disable both of these C states, the CPU will limit the maximum turbo boost multiplier. If you have a 4 core CPU, it will be limited to the 4 Active core multiplier. If you have a 6 core CPU, it will be limited to the 6 Active core multiplier. Depending on what CPU you have, a FIVR screenshot might show what the default turbo multipliers are for your CPU. 

 

17 hours ago, Haswellx86 said:

But whenever I put some load such as opening the start menu, I saw the frequency always drop a little and the multiplier as well.

That is how most Intel CPUs work when set to default settings. As more cores become active, the maximum CPU speed will drop. As cores become inactive, the speed of the active cores will increase. The actual CPU speed can be very dynamic, especially when a CPU is lightly loaded. The BCLK will run at a fixed speed but the multiplier can be changing hundreds of times per second.  

 

17 hours ago, Haswellx86 said:

the 100% C0 frequencies and Turbostat is wrong.

A lot of monitoring software chooses to fudge things a little. Most people do not need to know the precise CPU speed, especially when it is randomly and frequently changing. The data that ThrottleStop reports is very accurate but for some, it can be "too much information".  

 

17 hours ago, Haswellx86 said:

I even have all core turbo ratios to max

Only unlocked K, HX or HK series CPUs support an all core turbo setting at the maximum multiplier. Post some screenshots so I don't have to guess what CPU model you have.

 

17 hours ago, Haswellx86 said:

Damn I didn't know we had such important people on this forum.

Important is debatable. My wife was never impressed by the amount of time I spend on the forums so she divorced me! 

 

There are lots of knowledgeable people that like to share what they know on Linus Tech Tips. It is a good forum that I enjoy contributing to. 

[Haswellx86]

50 minutes ago, unclewebb said:

If I am the guy that wrote the program then of course I have the source.  A lot of the original TS source code was actually borrowed from RealTemp. 

Any reason you don't want to make it open source? And how hard would it be to port it on Linux? MSRs are easy to read on Linux. And it's okay to not develop a GUI for us Linux nerds (I am using the output data to parse anyways).

 

50 minutes ago, unclewebb said:

What CPU?

Forgot to mention that has a 10210U. The Linux one has a 8350U.

 

50 minutes ago, unclewebb said:

Most Intel mobile CPUs

So this is an actual mobile CPUs thing? Because your 10850K seemed to run very steady multipliers as you showed. It was just a screenshot so idk how the multipliers go under and off the load.

 

50 minutes ago, unclewebb said:

That is how most Intel CPUs work when set to default settings. As more cores become active, the maximum CPU speed will drop.

Oh wait, so are you talking about turbo ratio limits? That explains why it locked to 3.9 GHz when in 100% C1 (or C0) because my lowest ratio is 3.9 GHz.

 

50 minutes ago, unclewebb said:

Only unlocked K, HX or HK series CPUs support an all core turbo setting at the maximum multiplier.

So I guess it is only updating in the GUI but not applying the change. That also explains why I noticed that my 8350U laptop generally turbos more towards its max frequency all the time because in i7z I can see that the all core turbo multipliers are set to 36x on all 4 cores. It does turbo to 3.6 on all cores in 100% C0. And on my Windows laptop I remember seeing different values for the cores.

 

50 minutes ago, unclewebb said:

Important is debatable.

You are very. I didn't know TS was really only written by one guy. It's an awesome program.

 

50 minutes ago, unclewebb said:

My wife was never impressed by the amount of time I spend on the forums so she divorced me!

Don't ever feel guilty. You need to live how you gotta live. Don't change your personality on guilt but rather what you feel is correct or you want to do. And so choosing the right partner is important.

 

edit - So I also have another question. If my 8350U is configured to run at 36x all cores, does that mean it is actually running at 3591 MHz all the time and whatever frequency is being reported is error due to C states? Because whenever I do enter 100% C1 or C0, it does show as 3591 always and whatever fluctuation I always say about is only 1-2 MHz which is just reading error when in C1 or C0 but when idling, the frequency really is kind of all over the place (but not the power saving frequencies I am talking about, i.e., still turboing upwards to 3.6 GHz).

 

I also wanted to say that I love the Power Limit features in ThrottleStop. I found out that my 8350U system can lift off the power limits fully. And in Linux that works too. But my 10210U system cannot due it. I can change the numbers how much ever I want in TS but it PL1 max is set to 15 watts always. And actually under Linux, it's very disappointing because for whatever reason, the package just can't clamp to PL2 at all. Always stuck at the 15w PL1. Tried a lot to change it. Perhaps you know something, but I think it's just Linux's fault. I would like if I could also lift the PL1 or at least get my PL2 in Linux.

[unclewebb]

On 5/18/2025 at 9:19 AM, Haswellx86 said:

Any reason you don't want to make it open source?

The signed driver ThrottleStop uses is not open source. I did not write that driver. I am allowed to use that driver but I cannot redistribute it. I have no plans on releasing the rest of the ThrottleStop code as open source. 

 

On 5/18/2025 at 9:19 AM, Haswellx86 said:

your 10850K seemed to run very steady multipliers

The 10850K is an unlocked K series CPU. This allows one to set the Turbo Groups or Turbo Ratios however you like. You cannot do that with an Intel U series CPU. Setting Group 0 to 50 and 10 tells a 10850K to use the 50 multiplier whether 1 core is active or all 10 cores are active. 

 

 

 

On 5/18/2025 at 9:19 AM, Haswellx86 said:

So I guess it is only updating in the GUI but not applying the change.

You can use ThrottleStop to make turbo ratio requests but the CPU itself has to support whatever you are asking it to do. 

 

On 5/18/2025 at 9:19 AM, Haswellx86 said:

whatever fluctuation I always say about is only 1-2 MHz

If the CPU is loaded, not throttling and is using the 36 multiplier, ThrottleStop should not be reporting any fluctuation. If you are seeing a MHz fluctuation while in Linux, that is likely just monitoring error. 

 

On 5/18/2025 at 9:19 AM, Haswellx86 said:

8350U

Most U series CPUs reduce the max speed depending on how many cores are active. The 8350U is one of the very few Intel U series CPUs that can run the same 36 multiplier no matter how many cores are active. The FIVR Turbo column shows the default values. 

 

 

The default BCLK tends to be somewhere very close to 99.768 MHz. This frequency is very consistent from one 8th Gen U CPU to the next. I am guessing that this BCLK frequency is being generated within the CPU. Max speed should be a consistent 3591.65 MHz (36 X 99.768 MHz) or very close to that number. Variations of +/- 1 MHz or 2 MHz is usually just monitoring error. Wild swings outside that range can be caused by the CPU rapidly entering and exiting various C states. This can confuse some monitoring programs so once again you might just be seeing monitoring error.

 

On 5/18/2025 at 9:19 AM, Haswellx86 said:

my 10210U system cannot do it

Did you try checking the MMIO Lock box in the ThrottleStop TPL window? Checking this box will eliminate the secondary MMIO power limits from limiting the CPU. There is still a third set of turbo power limits that are managed by an EC. ThrottleStop cannot be used to control the EC power limits.

 

Not all 10th Gen U series CPUs use EC power limits. The performance of a 10th Gen U CPU is quite amazing when all of the turbo power limits have been removed. Being able to run one fully loaded at 63W or 64W is not too bad for a CPU that only has a 15W TDP rating. 

 

On 5/18/2025 at 9:19 AM, Haswellx86 said:

It's an awesome program.

You are welcome. I like using it too. It gives users a lot of control over a wide range of Intel CPUs released in the last 17 years. ThrottleStop continues to support the old Core 2 Duo processors.