Linux CPU Speed Reporting

Linux has multiple means of reporting CPU speed. This can make hardware discovery difficult depending on what source you attempt to use as your reference point. You may discover that two sources, such as cpuinfo and dmidecode produce entirely different results. Your first inclination will probably be that one of these is inaccurate but there is generally a reason for this disparity.

In my examples I will be working from Red Hat Enterprise Linux 4 running on an HP DL585 G2 using dual-core CPUs. This model uses AMD Opteron processors which are natively 64bit and based on the AMD64 architecture (a.k.a. x86-64 or x64.)

We will begin by looking at the output of dmidecode. Dmidecode is the most standard method for retrieving this type of information. We know that all four of our processors will be identical due to SMP limitations so we will not bother to look at all four of them – one will be sufficient. Using dmidecode we can retrieve both the Max Speed of the board as well as the Current Speed of the installed processors.

dmidecode | grep "Current Speed" | head -n 1
Current Speed: 2400 MHz

dmidecode | grep "Max Speed" | head -n 1
Max Speed: 2400 MHz

In this case we can see that we are dealing with processors of 2.4GHz which, according to dmidecode, is the fastest processor available for this revision of the motherboard. Often maximum speeds can be changed by the BIOS so do not be surprised if a firmware update changes this number. The “head -n 1” is simply for clarity to remove the extra processors – they all show identical information. Dmidecode pulls its information directly from the system firmware.

Cpuinfo in the proc filesystem is full of very useful CPU information and should be a primary source of discovery. In should be noted, however, that /proc/cpuinfo can be misleading if used incorrectly but that it contains some of the most important information to our system. Again we will only look at a single CPU instance in this example.

grep MHz /proc/cpuinfo | head -n 1
cpu MHz : 1004.694

In this case we see that cpuinfo is reporting to us that the processors are running at just 1GHz. This is a very different number than what we saw with dmidecode. The reason for the difference in the reported speed is that dmidecode is showing the processor’s rated speed – more or less its model number. This is why the speed is an even number. Cpuinfo, on the other hand, is reading the current speed directly from the CPU clock. Normally we would expect these numbers to be very close to each other with an acceptable degree of rounding. This dramatic difference in speeds is because the server is mostly idle and the CPU has been stepped down by the kernel to save power while it is not needed. This is an important power saving characteristic of newer processors and needs to be taken into account when using CPU speed reporting tools.

We can find additional information, as detected during the boot process, from dmesg. Dmesg will give us the maximum detected speed of our process as well as some very useful information if we just know where to look.

dmesg | grep "MHz processor"
time.c: Detected 2411.266 MHz processor.

dmesg | grep "powernow" | head -n 6
powernow-k8: Found 8 Dual-Core AMD Opteron(tm) Processor 8216 processors (version 2.00.00-rhel4)
powernow-k8: 0 : fid 0x10 (2400 MHz), vid 0xa
powernow-k8: 1 : fid 0xe (2200 MHz), vid 0xc
powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xe
powernow-k8: 3 : fid 0xa (1800 MHz), vid 0x10
powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0x12

As you can see from the first command output, dmesg tested the processors and determined that they are approximately 2.4GHz which corresponds to the rated speed as shown by dmidecode. We can see here that dmesg believes that this server has eight CPUs which is technically correct as each Opteron in this configuration is truly two processors. This is confusing, though, because it reports eight dual-core processors which is not correct. There are four dual-core processors here. Each dual-core is two discrete processors for eight total with just four sockets (semantic difference between the die configuration of Intel and AMD chips.)

What we are really interested in, in the above output, is the five PowerNow K8 levels – zero through four. These are the five speed steps available to our processors. When viewing the output of /proc/cpuinfo we should see the processor to be at one of the speeds indicated here as being available to us. This can be extremely useful information.

We can also discover some simple CPU count information through our first two tools. Each tool views the system differently so we need to be aware of what we are looking at. Dmidecode views the system from a socket perspective and cpuinfo views the system from a core perspective (which can be either an independent CPU or cores within a single CPU – AMD versus Intel ideology.)

dmidecode | grep "Central Processor" | wc -l

grep processor /proc/cpuinfo | wc -l

As you can see, it is important to know which view of the processor you are speaking about. This will become ever more important as CPUs continue to increase in cores per CPU, CPUs per socket and threads per core!

To gain more insight into the CPU discovery process I will now run through the same examples but on an HP DL380 G5 server using two quad-core Intel XEON processors based on its Core 2 architecture.

dmidecode | grep "Current Speed" | head -n 1
Current Speed: 2333 MHz

dmidecode | grep "Max Speed" | head -n 1
Max Speed: 4800 MHz

grep MHz /proc/cpuinfo | head -n 1
cpu MHz : 2333.337

dmesg | grep "MHz processor"
time.c: Detected 2333.337 MHz processor.

dmidecode | grep "Central Processor" | wc -l

grep processor /proc/cpuinfo | wc -l

Unfortunately the trick used on the AMD Opteron to display the steppings of the PowerNow architecture does not work with the Intel processors. But we can see here how the discrepancy between processor reporting methods varies even more dramatically as we move towards more multi-core processors.

Join the Conversation


  1. Excellent and timely article (at least for me, I was just searching for this type of info). One issue I’m seeing, though, is getting a proper reading of current cpu speed in an overclocked scenario. I have an AMD Athlon 64 X2 4200+, which is a dual core 2.2GHz. I’ve pushed it to 2.4GHz (2398.33MHz, to be exact). Here is the output of the above commands for my system:

    # dmidecode | grep “Current Speed” | head -n 1
    Current Speed: 2400 MHz
    # dmidecode | grep “Max Speed” | head -n 1
    Max Speed: 3000 MHz
    # grep MHz /proc/cpuinfo | head -n 1
    cpu MHz : 1000.000
    (pegged the cpu, then ran again:)
    # grep MHz /proc/cpuinfo | head -n 1
    cpu MHz : 2200.000
    # dmesg | grep “MHz processor”
    time.c: Detected 2398.330 MHz processor.
    # dmesg | grep “powernow” | head -n 6
    powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ processors (2 cpu cores) (version 2.00.00)
    powernow-k8: 0 : fid 0xe (2200 MHz), vid 0x8
    powernow-k8: 1 : fid 0xc (2000 MHz), vid 0xa
    powernow-k8: 2 : fid 0xa (1800 MHz), vid 0xc
    powernow-k8: 3 : fid 0x2 (1000 MHz), vid 0x12

    So I’m wondering, how can I tell my actual current cpu speed, given that it’s overclocked. dmidecode reports it, but only shows the static top value, not current speed as shifted by the powernow code. Any ideas? Thanks!

  2. To actually test you CPU speed you will need a dedicated utility for that. I don’t believe that there is any native Linux utility (at least not in Red Hat and SUSE that I use on my servers) that will definitely get you the resultant speed on an overclocked CPU.

    If your PowerNow is turned on, then the CPU will get clocked down and won’t run at the overclocked speed – at least not all of the time. You can force your CPU higher by changing the Front Side Bus (FSB) frequency but voltage and stepping will get overridden by the PowerNow controls. So once they kick in it all goes haywire.

    You can disable the CPU speed changes to guarantee that you get the fastest possible speed but this will result in a lot of power consumption and heat generation. You will need to disable Cool’n’Quiet in the BIOS and stop running processes like “cpuspeed”.

  3. Thanks!
    I had noticed a few days ago that my X2 4200+ was shifting between 1.8Ghz and 2.2Ghz in /proc/cpuinfo. I was wondering why it did that.. now I know!
    Thanks again!

Leave a comment