Detecting CPU Speed

General Method

In order to tell what's the CPU speed, we need two things:

1. being able to tell that a given (precise) amount of time has elapsed.
2. being able to know how much 'clock cycles' a portion of code took.

Once these two sub-problems are solved, one can easily tell the CPU speed using the following :

Note that except for very special cases, using a busy-loop (even calibrated) to introduce delays is a bad idea and that it should be kept for very small delays (nano or micro seconds) that you must comply when programming hardware only.

Also note that PC emulators (like BOCHS, for instance) are rarely realtime and that you shouldn't be surprised if your clock appears to run faster than expected on those emulators.

Waiting for a given amount of time

There are two circuits in a PC that allows you to deal with time: the PIT (Programmable Interval Timer, 8253 iirc) and the RTC (Real Time Clock). The PIT is probably the better of the two for this task.

The PIT has two operating mode that can be useful for telling the cpu speed:

1. the periodic interrupt mode (0x36), in which a signal is emitted to the interrupt controller at a fixed frequency. This is especially interresting on PIT channel 0 which is bound to IRQ0 on a PC.
2. the one shot mode (0x34), in which the PIT will decrease a counter at its top speed (1.19318 MHz) until the counter reaches zero.

Whether or not an IRQ is fired by channel0 in 0x34 mode should be checked

Note that theorically, _one shot_ mode could be used with a _polling_ approach, reading the current count on the channel's data port, but I/O bus cycles have unpredictable latency and one should make sure the timestamp counter is not affected by this approach.

Knowing how many cycles your loop takes

This step depends on your CPU. On 286, 386 and 486, each instruction took a well-known and deterministic amount of clock cycles to execute. This allowed the programmer to tell exactly how many cycles a loop iteration took by looking up the timing of each instruction and then sum them up.

Since the multi-pipelined architecture of the Pentium, however, such numbers are no longer communicated (for a major part because the same instruction could have variable timings depending on its surrounding, which makes the timing almost useless)

It is possible to create code which is exceptionally pipeline hostile such as:

A simple xor instruction takes one cycle, and it's guaranteed that the processor cannot pipeline this code as the current instructions operands depend on the results from the last calculation. One can check that, for a small count (tested from 16 to 64), RDTSC will show the instruction count is almost exactly (sometimes off by one) the cycles count. Unfortunately, when making the chain longer you'll start experiencing code cache misses, which will ruin the whole process.

E.g. looping on a chain of 1550 XORs may require a hundred of iterations before it stabilizes around 1575 clock cycles on a AMDx86-64, and I'm still waiting it to stabilize on my Pentium3

Despite this inaccuracy it gives relatively good results across the whole processor generation given a reasonably accurate timer but if very accurate measurements are needed the next method should prove more useful.

A Pentium developer has a much better tool to tell timings: the _Time Stamp Counter_: an internal counter that can be read using RDTSC special instruction

rdtscpm1.pdf explains how that feature can be used for performance monitoring and should provide the necessary information on how to access the TSC on a pentium

RDTSC Instruction Access

The presence of the Time Stamp Counter (and thus the availability of RDTSC instruction) can be detected through the [CPUID] instruction. When calling cpuid with eax=1, you'll receive the features flags in edx. TSC is the bit #4 of that field.

Note that prior to use the CPUID instruction, you should also make sure the processor support it by testing the 'ID' bit in eflags (this is 0x200000 and is modifiable only when CPUID instruction is supported. For systems that doesn't support CPUID, writing a '1' at that place will have no effect)

In the case of a processor that does not support CPUID, you'll have to use more eflags-based tests to tell if you're running on a 486, 386, etc. and then pick up one of the 'calibrated loops' for that architecture (8086 through 80486 may have variable instruction timings).

Working Example Code

There is a RealMode Intel-copyrighted example in the above-mentionned application note ... Here comes another code submitted by DennisCGC that will give the total measured frequency of a pentium processor.

Some notes:

• irq0_count is a variable, which increases each time when the timer interrupt is called.
• in this code it's assumed that the [PIT] is programmed to 100 hz (of course, I give the formula about how to calculate it
• it's assumed that the command CPUID is supported.

See the intel manual (see links) for more information.

- bugs report are welcome. IM to DennisCGC

Without Interrupts

I'd be tempted to say 'yes', though I haven't gave it a test nor heard of it elsewhere so far. Here is the trick:

Now, we know that

• ticks=(0x10000 - (hi*256+lo)) periods of 1/1193180 seconds have elapsed at least and no more than ticks+1.
• etsc-stsc clock cycles have elapsed during the same time.

Thus (etsc-stsc)*1193180 / ticks should be your CPU speed in Hz ...

As far as i can say, 0x1000 iterations lead to 10 PIT ticks on a 1GHz CPU and a bit less than 0x8000 ticks on the same CPU running BOCHS. This certainly means that on very high speed systems, the discovered speed may not be accurate at all, or worse, less than 1 tick could occur ...

This technique is currently under evaluation in [the forum|Forum:5849]

- hope you like my technique /PypeClicker

Asking the SMBios for CPU speed

The SMBios (System Management BIOS) Specification addresses how motherboard and system vendors present management information about their products in a standard format by extending the BIOS interface on Intel architecture systems. The information is intended to allow generic instrumentation to deliver this information to management applications that use DMI, CIM or direct access, eliminating the need for error prone operations like probing system hardware for presence detection.

SMBios Processor Information

A Processor information (type 4) structure describes features of the CPU as detected by the SMBios. The exact structure is depicted in section 3.3.5 (p 39) of the standard. Within those informations will you find the processor type, family, manufacturer etc. but also

• the External Clock (bus) frequency, which is a word at offset 0x12,
• the Maximum CPU speed in MHz, which is a word at offset 0x14 (e.g. 0xe9 is a 233MHz processor),
• the Current CPU speed in MHz, (word at offset 0x16).

Getting the SMBIOS Structure

SMBios provide a _Get SMBIOS Information_ function that tells you how many structures exists. You can then use _Get SMBIOS Structure_ function to read processor information.

As an alternative, you can locate the _SMBIOS Entry Point_ and then traverse manually the SMBIOS structure table, looking for type 4.

All this is depicted in 'Acessing SMBIOS Information' structure of the standard (p 11).

The SMBIOS Entry Point structure, described below, can be located by application software by searching for the anchor-string on paragraph (16-byte) boundaries within the physical memory address range 000F0000h to 000FFFFFh. This entry point encapsulates an intermediate anchor string that is used by some existing DMI browsers.

00-03	Anchor String (_SM_ or 5f 33 4d 5f)
04	Checksum
05	Length
06	major version
07	minor version
08-09	max structure size
0A	entry point revision
0B-0F	formatted area
10-14	_DMI_ signature
15	intermediate checksum
16-17	structure table length
18-1B	structure table (physical) address
1C-1D	number of SMBIOS structures
1E	SMBIOS revision (BCD)

I don't feel like re-explaining the PnP calling convention etc. as chances are it will be useless in ProtectedMode ...

Links

Other resources

• http://www.cs.usfca.edu/~cruse/cs630/lesson23.ppt, a crash course on PIT, and how to use it to compute CPU speed.
• http://www.sandpile.org/post/msgs/20004561.htm
• http://www.midnightbeach.com/jon/pubs/rdtsc.htm

• ftp://download.intel.com/support/processors/procid/

especially section 12: "Operating Frequency" on page 29 of 24161815.pdf

Regarding SMBIOS

• http://www.dmtf.org/standards/smbios
• http://www.dmtf.org/standards/documents/SMBIOS/DSP0134.pdf
• http://www.pcpitstop.com/faq/smbios.asp