Is the frequency of a CPU a mean value of about how many clock ticks there are in a second or does it have a more strong, physical stability?

In my opinion, it must be not stable nor unstable. So is there any information available about the variance for a CPU?

Is a CPU's cycle duration strictly synchronized to the crystal vibration? Or does the CPU just have to be sure to achieve a cycle before the next tick?

  • 7
    There are many different types of CPU. Most use a crystal which vibrates at a specific frequency to time themselves. Meaning that most are about as accurate as a digital wristwatch (which uses the same type of crystal to keep time). en.wikipedia.org/wiki/Crystal_oscillator
    – krowe
    Feb 8, 2015 at 21:08
  • 5
    @Gael some instructions take hundreds of ticks, or clock cycles, to complete.
    – misha256
    Feb 8, 2015 at 21:50
  • 1
    @Gael: Also, it's pretty common for CPUs to slow themselves down or speed themselves up, and they do it pretty often. Though I don't know exactly how that relates to ticks. Feb 9, 2015 at 17:29
  • 18
    Voting to close this as seeking product, service, or learning material recommendations? Really, people?
    – user
    Feb 9, 2015 at 19:41
  • 30
    This is a legitimate question seeking to clarify how hardware works.
    – studiohack
    Feb 9, 2015 at 20:34

5 Answers 5


Like any complicated thing, you can describe the way a CPU operates at various levels.

At the most fundamental level, a CPU is driven by an accurate clock. The frequency of the clock can change; think Intel’s SpeedStep. But at all times the CPU is absolutely 100% locked to the clock signal.

CPU instructions operate at a much higher level. A single instruction is a complex thing and can take anywhere from less than one cycle to thousands of cycles to complete as explained here on Wikipedia.

So basically an instruction will consume some number of clock cycles. In modern CPUs, due to technologies like multiple cores, HyperThreading, pipelining, caching, out-of-order and speculative execution, the exact number of clock cycles for a single instruction is not guaranteed, and will vary each time you issue such an instruction!


is there any information available about the variance for a specific CPU?

Yes and no. 99.99% of end-users are interested in overall performance, which can be quantified by running various benchmarks.

What you're asking for is highly technical information. Intel does not publish complete or accurate information about CPU instruction latency/throughput.

There are researchers who have taken it upon themselves to try figure this out. Here are two PDFs that may be of interest:

Unfortunately it's hard to get variance data. Quoting from the first PDF:

numbers listed are minimum values. Cache misses, misalignment, and exceptions may increase the clock counts considerably.

Interesting reading nevertheless!

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Sathyajith Bhat
    Feb 9, 2015 at 13:06
  • 4
    Very nice. Of course, But at all times the CPU is absolutely 100% locked to the clock signal only applies to synchronous CPUs. It's silly to talk about ticks in an asynchronous (clock-less) CPU, but it felt like an omission to me :)
    – Luaan
    Feb 10, 2015 at 17:28
  • 1
    @Luaan - True. I think that true asynchronous CPUs are still quite rare, but they do exist (or have in the past). Only really relevant to researchers and hardware geeks, though. Feb 11, 2015 at 19:25
  • @DanielRHicks They were of some interest for embedded devices (there's some old MIPS and ARM asynchronous CPUs around), but yeah, not really the big thing on the consumer market. After all, why care about the CPU power consumption of a smartphone when there's the power hungry display right next to it. The power savings (and other features) might be very cool for some other applications, though - the IBM SyNAPSE looks like a cool project for scientific purposes.
    – Luaan
    Feb 12, 2015 at 7:52
  • @Luaan - The interesting point, back when they were first being invented, was that the computer ran exactly as fast/slow as it needed to to perform the computation. But more elaborate clocking schemes basically accomplished the same thing, sorta. Feb 12, 2015 at 12:41

Are CPU clock ticks strictly periodic in nature?

Of course not. Even the very, very best clocks aren't strictly periodic. The laws of thermodynamics say otherwise:

  • Zeroth law: There's a nasty little game the universe plays on you.
  • First law: You can't win.
  • Second law: But you just might break even, on a very cold day.
  • Third law: It never gets that cold.

The developers of the very, very best clocks try very, very hard to overcome the laws of thermodynamics. They can't win, but they do come very, very close to breaking even. The clock on your CPU? It's garbage in comparison to those best atomic clocks. This is why the Network Time Protocol exists.

Prediction: We will once again see a bit of chaos when the best atomic clocks in the world go from 2015 30 June 23:59:59 UTC to 2015 30 June 23:59:60 UTC to 2015 1 July 2015 00:00:00 UTC. Too many systems don't recognize leap seconds and have their securelevel set to two (which prevents a time change of more than one second). The clock jitter in those systems means that the Network Time Protocol leap second will be rejected. A number of computers will go belly up, just like they did in 2012.

  • 9
    +1, funny and informative. And the Leap Second topic is a good reading, too.
    – jimm-cl
    Feb 9, 2015 at 7:36
  • 10
    Well, IIRC, the go-belly-up wa caused because the kernel clock routines were aware of the possibility of leap seconds, but implemented the adjustment as a call to a clock adjustment routine that was not allowed to be called while the clock was already being adjusted ... And of course the system clock has nothing to do with the cpu clock. Feb 9, 2015 at 9:10
  • 1
    Lol, awesome. I have to add something to your "CPU clock is garbage compared to atomic clocks" observation: Indeed! But it's all very subjective, not to mention relative. We may marvel at the superior accuracy of our best atomic clocks, but somewhere out there (outside of our cozy reality) there may be technology that makes our atomic clocks look like "garbage" :-p
    – misha256
    Feb 9, 2015 at 10:48
  • 2
    @misha256 the reality is there can be no accurate clock. Time is relative.
    – Keltari
    Feb 9, 2015 at 20:50
  • The CPU clock can be garbage, but there's nothing like letting an 8-bit register overflow just to give some time to the 7-segment display driver in an unknown state to chomp up your instruction before you issue the next one. We don't need no crystals for that. Or even more importantly, there's nothing like waiting a nanosecond for the ALU to complete its computation before you stash away its results into a register (or onto a bus leading to a different ALU). Feb 11, 2015 at 13:24

Around 2000, when clockspeeds of CPUs started to get into the range where mobile phones also operated, it became common to add a variation to the actual clock speed. The reason is simple: If the CPU clock is exactly 900 Mhz, all the electronic interference is generated at that frequency. Vary the clock frequency a bit between 895 and 905 Mhz, and the interference is also distributed over that range.

This was possible because modern CPU's are heat-limited. They have no problem running slightly faster for a short period of time, as they can cool down when the clock is slowed down later.

  • 13
    In the BIOS you'll often see this option described as "Spread Spectrum"
    – Mark Sowul
    Feb 9, 2015 at 17:06
  • 1
    I have read that in multi-core CPUs the cores are also using offset clocks because it helps avoid radio noise, helps with power distribution, and avoids the cores building harmonics.
    – Zan Lynx
    Feb 11, 2015 at 0:13
  • 3
    @MarkSowul thanks, finally someone telling the practical use of this "spread spectrum".
    – user256743
    Feb 12, 2015 at 11:07

Digital logic designer here. The actual time taken for a logic network to change in response to an input signal is the propagation delay. Think of the system as:

registers A,B,C... ---> logic cloud ---> registers A',B',C'

The "launch clock" is the clock edge at which time the first set of registers change. The "capture clock" is the next clock edge one period later. In order for the system to work the output of the logic cloud has to be stable before the capture clock arrives.

The process of making sure this works is timing analysis. Using a physics-based simulation of the system, work out the worst case arrival time of any input to any output. The largest of these numbers across the system sets the minimum clock period.

Note worst case. The actual propagation time will be shorter, but it depends on manufacturing process variation, current temperature, and chip voltage (PVT). This means in practical terms you can apply a faster clock (overclocking) and it may work. It may also start producing errors, such as deciding that 0x1fffffff + 1 = 0x1f000000 if the carry bit doesn't arrive in time.

Chips may also have more than one clock on board (usually the FSB is slower than the core), and the actual clock may be ramped up or down for thermal control purposes or varied (MSalter's answer about using spread spectrum for passing EMC tests).

  • In some cases, the capture clock may be the second or later cycle rather than the next. Some designs assume that data will always take at least some minimum amount of time (e.g. if propagation delay is known to be between 2.1 and 2.9 cycles, data could be output and results sampled on every cycle; each sampled result would reflect the data from 3 cycles before); other more conservative designs change the output data more slowly, and ignore the result until it is guaranteed to be stable.
    – supercat
    Mar 27, 2015 at 15:35

Is a CPU's instruction duration strictly synchronized to the crystal vibration? Or does the CPU just have to be sure to achieve an instruction before the next tick?

Neither. The instruction duration will be some number of clock ticks, but that number can vary based on the requirements of the instruction. For example, if an instruction can't make forward progress until a particular memory location is in the L1 cache, then the instruction will not be completed before the next clock tick. No forward progress on that instruction will be made until that happens.

But when the CPU does decide to do something, the basic method by which it does it is to set up its internal switches so that a particular piece of information goes to a particular portion of the CPU. The it waits for the input to arrive at that portion and the output to arrive at the next portion. This waiting portion is the purpose of the clock.

Imagine a physical circuit that takes two binary inputs and sums them, outputting the sum on some third set of wires. To do an addition, the CPU must arrange for the two numbers to be added to get to this adder and the outputs to go to, say, a CPU register latch. The CPU can't tell the latch to store the output until the inputs reach the adder, the adder produces the output, and the output reaches the latch. This is the purpose of the clock -- to set the wait time between arranging input to go somewhere and expecting the output to be ready to use.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .