A processor has no concept of time. It has a pin that changes state at a rate it cannot itself measure, and every notion of duration and timestamp inside the machine is assembled by counting those transitions. That distinction, between an oscillation the hardware can count and a time it can only be told, accounts for most of what goes wrong with clocks in computing.
The oscillator
The rate comes from quartz. The material is piezoelectric, so applying a voltage deforms it and deforming it produces a voltage. Cut to shape, a blank becomes a mechanical resonator with a sharply defined natural frequency, and placed in an amplifier feedback loop the circuit sustains oscillation there, because that is the only frequency at which the loop returns enough energy in phase to keep going.
What makes quartz worth using is its selectivity. The resonator has a quality factor in the tens of thousands, so it stores energy efficiently at its own frequency and rejects everything nearby. A low quality resonator drifts wherever the surrounding circuit nudges it. Quartz refuses to be nudged far, and that stubbornness is the entire value.
The crystal on a board typically runs at tens of megahertz. The core does not. A phase locked loop multiplies the reference by comparing a divided copy of a fast oscillator against it and steering until the two agree. The important consequence is that the multiplied clock inherits the accuracy of the reference. A phase locked loop creates frequency, not precision that was never in the crystal.
Counting is not timekeeping
Counting cycles yields an interval only if the rate is known and constant, and for a long period neither held. The x86 time stamp counter increments every cycle and can be read in a few instructions, which made it attractive for short measurements. Early implementations tied it to the core frequency, so it slowed under power management, stopped in deep sleep, and advanced independently per socket, meaning a migrated thread could observe time moving backwards.
Later processors provide an invariant counter advancing at a fixed rate regardless of what the core is doing, and operating systems check for that guarantee before trusting it.
The clock that survives power off
Alongside it sits the real time clock, a small always powered block with its own battery and its own crystal at 32768 Hz. That number is two raised to the fifteenth power, so fifteen binary dividers reduce it to exactly one pulse per second using nothing but flip flops.
It holds the calendar while the machine is off. It is not accurate, it is persistent, and those are different properties.
Why the clock drifts
Crystal error is quoted in parts per million, and a commodity part is specified between twenty and fifty. Twenty parts per million across the 86400 seconds in a day is about 1.7 seconds. Fifty is more than four. A machine left alone for a month can be minutes wrong, and it will be confidently wrong, because nothing inside it can detect the error.
Temperature is the largest contributor. The tuning fork cut used at 32768 Hz has a parabolic response with a turnover near room temperature, so the crystal loses time as conditions move away from that point in either direction. A phone in a pocket, then on a desk, then in a car is being driven along that curve continuously.
Compensation and ageing
Compensated and oven controlled oscillators fix this and cost accordingly, which is why they appear in base stations rather than handsets. Ageing adds a slower drift as mechanical stress relieves over years, small but one directional, so it does not average away.
None of this is a fault. A crystal is a physical object holding a rate to one part in a million while its environment changes, and it does that well. It simply does not do it well enough for a population of independent machines to agree, which is the actual requirement.
What each source is actually worth
| Source | Typical accuracy | Limited by |
|---|---|---|
| Uncorrected crystal | Seconds per day | Temperature and ageing |
| Network time over the internet | Milliseconds | Path asymmetry |
| Network time on a local network | Under a millisecond | Software timestamping |
| Precision time with hardware support | Under a microsecond | Switch and interface support |
| Local atomic reference | Nanoseconds | Cost |
Disciplining the clock
The Network Time Protocol corrects it. One exchange produces four timestamps: when the client sent, when the server received, when the server replied, and when the client received. Round trip delay is the total elapsed at the client minus the time the server held the request. Offset is the clock difference, estimated by assuming the delay divides evenly between the two directions.
That assumption is where accuracy is lost. Asymmetric routing or congestion in one direction only biases the estimate by half the asymmetry. Ten milliseconds more delay outbound than inbound produces a five millisecond error that averaging will never remove, because it is bias rather than noise. This is why a machine on a quiet local network holds sub millisecond accuracy while one behind a congested link is stuck in the milliseconds regardless of how often it polls.
Correction is applied by slewing rather than stepping wherever possible. The kernel adjusts the rate at which the clock advances so it converges without ever moving backwards. Stepping a clock backwards on a running system breaks anything that assumed time only increases, including file timestamps, lock expiry, and log ordering, so stepping is reserved for offsets too large to slew away in reasonable time.
When milliseconds are not enough
The Precision Time Protocol moves timestamping into hardware. A supporting network interface captures the time at the instant the packet crosses the physical layer, removing the operating system, the driver, and the transmit queue from the measurement, while switches along the path either report their own delay or regenerate the timing hierarchy. With hardware support at every hop, synchronisation below a microsecond is routine.
Why the accuracy is needed
The reason to care is operational. Correlating logs across a fleet requires comparable timestamps, and an investigation is worthless if the ordering is an artefact of clock error. Certificate validity, Kerberos tickets, and time based one time passwords fail outright beyond their tolerance. Distributed databases that order writes by timestamp resolve conflicts in favour of the wrong write, silently.
European rules oblige high frequency algorithmic trading systems to be traceable to Coordinated Universal Time within one hundred microseconds.
Leap seconds
Leap seconds add a discontinuity that precision alone does not handle. Coordinated Universal Time is occasionally adjusted by a whole second to stay aligned with the Earth's rotation, which is neither constant nor reliably predictable, and software that assumed every minute contains sixty seconds has failed on it repeatedly.
The common mitigation is to spread the adjustment across a day so no second is ever repeated or skipped, leaving the fleet deliberately offset from Coordinated Universal Time during that window. Internal consistency is judged the more important property, which is a reasonable trade for almost every system.
Two clocks in every program
Operating systems expose at least two clocks, and confusing them is the most common timekeeping defect in application code. The realtime clock reports wall time, is subject to correction, and can move in either direction. The monotonic clock reports elapsed time from an arbitrary point, never moves backwards, and is never adjusted.
Measuring a duration with the realtime clock is a defect even though it usually works. If a correction lands between the two readings the interval is wrong, and if the correction is negative the duration is negative, which produces a timeout that fires immediately or a retry loop that never sleeps.
Timeouts, backoff, rate limiting, and performance measurement belong on the monotonic clock. The realtime clock exists to record when something happened in terms another machine can interpret.
Note: the crystal in a typical machine holds its rate to roughly one part in a hundred thousand, which is excellent for a vibrating piece of quartz and useless for a distributed system. Every mechanism above exists to close that gap.