If you open the Settings app and go to System, About, the first information block contains basic hardware information like the processor and RAM. But why does the processor speed get reported twice, sometimes with slightly different values?
| Processor | Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz | 3.71GHz |
This field is actually showing two pieces of information, one after the other. Let’s break it down.
| Processor | Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz | 3.71GHz |
| Processor brand string | Speed |
The processor brand string comes from the unreliable CPUID function codes 0x80000002 through 0x80000004, which returns an arbitrary 47-character string¹ intended to be used for processor branding identification.
Some processor manufacturers include a CPU speed as part of that string,² which is why you see the “@ 3.60GHz” appended to the CPU identifier.
Windows itself does a rough calculation of the CPU speed and shows it after the processor brand string.
My guess is that this system is being 3% overclocked since 3.71 is 3% larger than 3.60.
¹ Really 48 characters, but it is required to be null-terminated, so only 47 useful characters.
² Perhaps they do it to make it easier to detect overclocking or systems being marketed as faster than they really are.
all modern CPUs have a dynamic speed
in the CPUID string you can see “base frequency”, but in real life CPU (CPU cores actually) can work at much higher or lower frequencies
Folks.. if cpuid didn't specify requirement for null-terminator, can you imagine the world of buffer-overrun bugs from sprintf calls, in thousands of diagnostic apps -- bugs that would only ever repro on the handful of cursed CPUs that chose to use all 48 chars without a terminating null? It would not be a very nice situation.
There are a handful of older Win32 APIs that can/could return fixed-size char buffers without null term -- iirc GetComputerName() is one. These have been problematic, for decades.
In my experience, people who work at msft and intl just want to make the world...
CPUID returns exactly 16 bytes of data, packed into four integer registers. 48 bytes of data fill up three calls completely — returning the length separately would demand a fourth call.
As for why not just allow 48 bytes of data, I assume requiring a null helps detect garbage returns?
They exactly don’t have a set speed any more, and the list of reasons the measured speed can change is too long. The CPU ID should show what you bought though.
My guess is that it’s a convenient way to represent variable-length strings. The popularity of null-terminated strings was probably a consideration as well.
> Really 48 characters, but it is required to be null-terminated, so only 47 useful characters.
This seems strange, why does it need to be null terminated? Is that just for the sake of C strings being null terminated?
> Windows itself does a rough calculation of the CPU speed
Is it perhaps showing the RDTSC timestamp counter frequency? (intentionally, or by accident?) I think that’s 3.7 GHz on many/most modern systems.