Leave a computer disconnected for a month and its clock will be visibly wrong. Nothing has broken. Clock drift is the ordinary behaviour of the cheap quartz oscillator that every machine uses to count time, and the only unusual thing about it is how rarely anyone notices, because a background service quietly corrects it several times an hour.
This article explains where the error comes from, why temperature matters more than component quality, how much drift is normal in seconds per day, what virtual machines and sleep do to make it worse, and how synchronisation removes it. To find out where your own machine stands, the clock accuracy check measures the offset between your device and a server reference.
What Causes Clock Drift?
A quartz crystal that vibrates at very slightly the wrong rate. The operating system counts those vibrations to advance the clock, so if the crystal runs a fraction fast, every second the machine measures is a fraction short, and the error accumulates without limit.
The crystal in most timekeeping circuits is cut as a tuning fork and specified at 32,768 hertz, a number chosen because it is two raised to the fifteenth power, so fifteen successive halvings produce a clean one-hertz tick. Manufacturing cannot hit that figure exactly. A watch crystal is typically sold with a tolerance of around twenty parts per million, and the crystals on computer motherboards are often looser still, perhaps fifty to a hundred parts per million. Nothing in that specification is a defect: closer tolerances cost more, and for a device that will be corrected over the network every few minutes there is no reason to pay for them.
Parts Per Million in Seconds Per Day
The arithmetic is easy and worth memorising. One part per million is 0.0864 seconds a day, because a day contains 86,400 seconds, so a crystal running twenty parts per million fast gains about 1.7 seconds every day.
- 20 ppm: roughly 1.7 seconds a day, or about ten minutes a year. This is a typical wristwatch or a good wall clock.
- 50 ppm: roughly 4.3 seconds a day, or half an hour a year. Common for an unremarkable computer.
- 100 ppm: roughly 8.6 seconds a day, close to an hour a year. The loose end of what mass-market hardware ships with.
- 0.1 ppm: under a hundredth of a second a day, achievable with a temperature-compensated or oven-controlled oscillator costing far more than the crystal it replaces.
Note that the direction is as fixed as the size. A given machine will almost always run fast or almost always run slow, at a rate that stays much the same from week to week, which is what makes the drift correctable in software rather than merely detectable.
Why Temperature Matters Most
A tuning-fork crystal is not equally accurate at all temperatures. Its frequency follows an inverted parabola with a peak near 25 degrees Celsius, and the rate falls away roughly with the square of the departure from that turnover point, so cold and heat both slow the clock.
The practical effect is large. A crystal ten degrees from its turnover loses a few parts per million on top of whatever its manufacturing offset was, and one sitting in a cold room or against a hot power supply can easily double the error printed on its datasheet, so temperature rather than manufacturing dominates the drift of most machines. This is also why the drift of a laptop changes with what the machine is doing: a long compile heats the board, the crystal warms, and the rate shifts while the fans are running. A device inside a warm case behaves differently from the same device idle on a desk, and neither matches the bench conditions under which the crystal was specified. Ageing adds a slow contribution of its own, usually around a part per million over the first year and less thereafter.
How Much Clock Drift Is Normal?
A few seconds a day for an ordinary desktop or laptop, and up to a minute a week for a poor one. Anything beyond that points to a specific fault rather than to ordinary quartz drift, and the usual culprits are easy to identify.
- Virtual machines: a guest counts timer interrupts the host may deliver late or not at all, so a busy hypervisor can starve a guest of ticks and cost it seconds an hour. Paravirtual clock sources solve most of it.
- Snapshots and migration: restoring a snapshot or moving a running machine between hosts resumes the guest with a clock frozen at the old moment, producing a jump rather than a slow error.
- Sleep and suspend: the battery-backed hardware clock keeps running while the system is asleep, but the counters the kernel uses do not, so the reading is corrected with a step at wake and short sleeps can leave a residue.
- A flat coin cell: when the hardware clock loses its battery the machine boots with an absurd date, which is a dead battery rather than any kind of drift.
Containers are a common source of confusion here and are not actually a cause. A container shares the host kernel and therefore the host clock, so if the time inside one is wrong, the host is wrong.
How Synchronisation Corrects Drift
A time client does two things: it measures the current offset and corrects it, and it measures the rate of drift and compensates for that too. The second is what keeps a machine accurate between polls rather than merely accurate at the moment it checks.
After a few exchanges with a server, the client can see that the local oscillator gains, say, four seconds a day, and it tells the kernel to advance the clock slightly more slowly to cancel it. That figure is written to a drift file, so a machine that reboots resumes with the correction already applied instead of relearning it from scratch. Corrections are applied by changing the rate rather than by jumping the reading, for the sake of software that assumes time moves forward smoothly, and the mechanism is described in what NTP is and how it works. A well-disciplined machine on a decent network holds within a few milliseconds indefinitely, which is thousands of times better than the raw crystal could manage. Setting it up takes a minute, as covered in how to sync your computer clock.
Why Atomic Clocks Do Not Drift This Way
Because their reference is an atom rather than a manufactured part. A caesium transition has the same frequency in every atom, at every temperature the apparatus permits, and does not age, so there is no tolerance to compensate for and no rate to relearn.
Everything downstream inherits that stability without inheriting the price. Your machine keeps its cheap crystal for the counting and takes a correction from a chain that begins at a national laboratory, which is a far better bargain than putting a good oscillator in every device. The physics is set out in how atomic clocks work, and you can see the end result against your own device on the live atomic time display.
Conclusion
Clock drift is not a fault. It is the expected consequence of counting time with a crystal specified to tens of parts per million, in a case whose temperature nobody controls, and it amounts to a few seconds a day on typical hardware. Virtual machines, snapshots and sleep make it worse and jumpier; synchronisation removes it by learning the rate of error and cancelling it continuously. If your clock is out by minutes rather than seconds, look for a flat battery or a failed sync rather than blaming the quartz. Measure yours on the clock drift checker, or begin at the atomicclock.now homepage.