Detecting CPU Speed: Difference between revisions

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

# beingBeing able to tell that a given (precise) amount of time has elapsed.

# beingBeing able to know how muchmany 'clock cycles' a portion of code took.

(nano or micro seconds) that you must complybe complied with when programming hardware only.

Also note that PC emulators (like BOCHS, for instance) are rarely realtime, andresulting in the clock appearing to run faster

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

The PIT has two operating modemodes that can be useful for telling the cpuCPU speed:

# the ''periodic interrupt'' mode (0x36), in which a signal is emitted to the interrupt controller at a fixed frequency. This is especially interrestinginteresting on PIT channel 0 which is bound to IRQ0 on a PC.

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

Note that theoricallytheoretically, _one''one shot_shot'' mode could be used with a _polling_''polling'' approach, reading the current count on the channel's data port, but I/O bus cycles have unpredictable latency and oneit is up to the programmer shouldto make sure the timestamp counter is not affected by this approach.

This step depends on yourthe CPU. On 286, 386 and 486, each instruction tooktakes

a well-known and deterministic amount of clock cycles to execute. This allowedallows

up the timing of each instruction and then sumsumming them up.

Since the multi-pipelined architecture of the Pentium,; however, such numbers are

variable timings depending on its surrounding, which makes the timing almost useless).

A simple xor instruction takes one cycle, and it'swhich guaranteedguarantees 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, whichwill willoccur, ruinruining the whole process.

E.g. [http://www.sylvain-ulg.be.tf/resources/speed.c 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'mwill stilltake waitingan itexceedingly long time to stabilize on mya Pentium3.

Despite this inaccuracy, it gives relatively good results across the whole processor generation given a reasonably accurate timer. but ifIf 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''Time Stamp Counter_Counter'': an internal counter that can be read using RDTSC special instruction

[http://www.math.uwaterloo.ca/~~jamuir/rdtscpm1.pdf 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 pentiumPentium.

The presence of the Time Stamp Counter (and thus the availability of RDTSC instruction) can be detected through the [CPUID] instruction. WhenCalling calling cpuidCPUID with eax=1, you'llwill receiveput the featuresfeature flags in edx. TSC is the bit #4four of that field.

Note that prior to useusing the CPUID instruction, you should also make sure the processor supportsupports it by testing the 'ID' bit in eflags. (thisThis 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. is running and then pick up one of the 'calibrated loops' for that architecture (8086 through 80486 may have variable instruction timings).

ThereA isReal a RealModeMode Intel-copyrighted example is present in the above-mentionnedmentioned application note ...

Here comes anotherAnother code snippet submitted by user DennisCGC that will give the total measured frequency of a pentiumPentium processor follows.

* inIn this code it's assumed that the [PIT] is programmed to 100 hzHz (ofThe course,formula Ito givecalculate thea formuladesired aboutHz howis toprovided calculatein itthe snippet.)

* it'sThe assumedcode assumes that the command CPUID is supported.

jnzjz detect_end ; no ?, go to detect_end

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

The [[SMBiosSMBIOS]] (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.

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 [http://www.dmtf.org/standards/documents/SMBIOS/DSP0134.pdf standard]. Within thosethat informations willinformation you will find the processor type, family, manufacturer etc. butand also:

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

* http://www.cs.usfca.edu/~cruse/cs630cs630s04/lesson23.pptppt‎, a crash course on PIT, and how to use it to compute CPU speed.