Sheep Guarding Llama

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
4

grep processor /proc/cpuinfo | wc -l
8

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
2

grep processor /proc/cpuinfo | wc -l
8

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.