I mean to determine the clock speed. I am posting below the output of the various commands listed here.
For the max freq, I see 4 different sources, with 2 different values:
CPU max MHz: 3300,0000
fromlscpu
.capacity: 3300MHz
fromlshw
.capacity: 3800MHz
fromsudo lshw
.Max Speed: 3800 MHz
fromdmidecode
.
For the current freq, I see 4 different sources, with roughly 3 different values:
CPU MHz: 2100.000
fromlscpu
.cpu MHz : 1691
(averaged by me) fromcat /proc/cpuinfo
.Current Speed: 2600 MHz
fromdmidecode
.Detected 2594.332 MHz processor
fromcat /var/log/dmesg
.
My observations:
- There was a wide variation in the output obtained, for both the max freq and current freq. How to make sense of this?
For instance,
lshw
gives different results with or withoutsudo
. Is this expected? Which should be considered more reliable, and why? - The clock speed was even different among the 4 processors. Is such a wide variation expected?
Note: As appropriately asked by @hobbs, this OP was motivated by the need for understanding the relation between "Clock speed" (whichever variant corresponds), CPU freq spec, and memory speed spec (here there is also possibly more than one value, see e.g. dmidecode showing Memory Module Voltage: 3.3 V for DDR3 RAM).
Output:
$ lscpu | grep "MHz"
CPU MHz: 2100.000
CPU max MHz: 3300,0000
CPU min MHz: 1200,0000
$ cat /proc/cpuinfo | grep "MHz"
cpu MHz : 1753.417
cpu MHz : 1200.000
cpu MHz : 2212.235
cpu MHz : 1600.000
$ lshw -c cpu | grep capacity
WARNING: you should run this program as super-user.
capacity: 3300MHz
$ sudo lshw -c cpu | grep capacity
capacity: 3800MHz
$ sudo dmidecode -t processor | grep "Speed"
Max Speed: 3800 MHz
Current Speed: 2600 MHz
$ cat /var/log/dmesg | grep "MHz processor"
[ 0.000000] kernel: tsc: Detected 2594.332 MHz processor
$ cat /var/log/kern.log | grep "MHz processor"
The following deductions are done entirely based on my own experiments and extrapolations. Also, part of the deduction is comparing the numbers with the official clock speeds reported by the CPU manufacturer.
This command shows the current clock for each processor core: (all subsequent commands run on Intel Atom C3558 CPU)
This command shows the current "average" (as observed by myself, purely based on trial) clock between cores (
CPU MHz
), and the max normal clock (CPU max MHZ
).Note that the current clock speed (both average and for each core) varies greatly over time (and possibly many times per second), as the system normally continuously throttles the CPU clock for powersaving (down to
CPU min MHZ
). I believe it is normal that this varies among CPU cores as well.This command also shows the max normal clock (
capacity
- should be the same asCPU max MHz
above).However, for my Intel Atom CPU this is only correctly reported without
sudo
(2200 MHz). Withsudo
, it reports a higher number (in this case also 3800 - this may be the max boosted clock, but I'm not sure in the case of an Atom CPU):For a Broadcom ARM CPU (on a Raspberry Pi 4), the value is the same both with and without sudo (1500 MHZ). I would guess this is because the Pi Arm CPU does not have boost/turbo mode.
Updated the answer at Any way to check the clock speed of my processor?
But in summary:
All the commands above will also give you the CURRENT cpu Hertz, meaning, if you expect to see the same one on lscpu and when doing the cat /proc/cpuinfo it will be near impossible. you CAN compare the maximum because that should show the same for any of the ways you can analyze the CPU, but the current will always be literally "the current CPU hertz" at the moment you execute it.
Lastly do note that dmidecode reads information from the ACPI tables which is not always the same as the real time ones done by the other tools.
So you got a couple of ways of getting the REAL current CPU and then you also have methods of getting what the ACPI Table registers (which in my case is super wrong).
This is why if you run lscpu multiple times, the current speed will always change, same for the /proc/cpuinfo. But for dmidecode it will stay (on many cases) with the same value, even if the value is a false positive.