Topics In Timekeeping · Timekeeping in Datacenters

How does GNSS holdover work?

Updated Aug 12, 2026 • GNSS, timing, datacenter, oscillators, buying

Skip the details — take me to the bottom line ↓

Nothing dramatic happens. The antenna goes deaf — a failed amplifier, a construction crew, a jammer in a passing truck — and your clock keeps producing seconds exactly as before. It just stops knowing whether they are the right ones.

That coasting is holdover, and the mechanism is simpler than the marketing: your clock keeps applying the frequency correction it was last told, and drifts as that correction goes out of date.

That state is called holdover, and the useful question is not how long can I hold over? It is how long until I have drifted past what I can tolerate? — which is a different question with a different answer for every reader, and the reason a number quoted without a threshold is worthless.

Holdover is not the same as free-running

Worth getting straight first, because the two get used interchangeably and the difference is load-bearing.

An oscillator that was never disciplined does not know its own frequency error. It runs at whatever rate its crystal happens to run at, and that rate is off by an amount nobody has ever measured.

A clock in holdover was disciplined until a moment ago. It has been steered for hours or days against GNSS, and in the process something learned its frequency offset to great precision. When the reference vanishes, that correction keeps being applied. The clock does not revert to its raw crystal — it coasts on the last thing it was told.

Why a holdover figure alone tells you nothing

“Twenty-four hours of holdover” is a specification-shaped object with no information in it. It needs two companions before it means anything.

Held over to what threshold? Twenty-four hours to 1 ms and twenty-four hours to 100 ns are different products at different prices.

On which oscillator? The same clock with the TCXO option and the rubidium option holds over differently by orders of magnitude, and vendors quote the good one.

Here is what that looks like with real arithmetic. This is our own error budget for an OCXO-class host in a thermally quiet room, holding over after the phase reference disappears — the same clock, read against two different thresholds:

One clock. Two honest answers: “about two minutes” and “about half an hour”. A factor of fifteen, decided entirely by a number the reader supplies and the datasheet cannot know.

The dominant term is usually your room

Here is the part that surprises people, and it is the most useful thing on this page.

The limit on holdover is not usually the oscillator’s intrinsic noise. It is temperature. An oscillator’s frequency moves with its temperature, and a room whose temperature is moving drags the frequency with it — far faster than the crystal would have wandered on its own.

The same budget, with the room misbehaving:

Roughly double to triple the error at the same elapsed time, from nothing but air. And a full-blown thermal transient can be five times worse again — the range we budget for runs from 0.01 ppb/min in a quiet room to 1 ppb/min while the temperature is genuinely moving, a factor of a hundred.

What that looks like when you catch it happening

This is from my own lab, and it is the most convincing thing I can show you on the subject.

The upper plot is the receiver’s quantization error — how far each pulse landed from where it wanted to be, bounded by one tick of the receiver’s internal clock. On its own that is just 8 ns of sawtooth. The information is in the slope.

How fast the sawtooth sweeps is the frequency offset between the receiver’s TCXO and GPS time. Early in the record the ramps run upward and repeat quickly. Near the middle they slow almost to a stop, pass through zero, and then start running the other way. Unwrap and accumulate that, and you get the lower plot: the oscillator’s phase walked out to 120 ns and came back, in eight minutes.

Nothing was wrong. The lab warmed slightly and then cooled — I had probably just turned on the ceiling fan on a warm afternoon. That is the entire cause, and the slide’s own conclusion is the right one: compare GPS time to quartz time and you have built a very expensive thermometer.

An oven-controlled oscillator helps precisely because it attacks this term: it holds the crystal at a constant temperature so the room’s temperature matters less. That is what you are buying, and it is why the improvement over a TCXO in holdover is far larger than the difference in their quoted stability figures suggests.

A holdover spec and a holdover measurement are different objects

This follows directly from the room dominating, and it is the part most likely to save you from a bad promise.

What moves an oscillator during holdover is mostly its environment — temperature above all, but also airflow across the case and what the supply rail is doing. Those are not properties of the oscillator. They are properties of the room, the rack, the season and the day.

So consider the two extreme rooms you could use for holdover testing.

The lucky room. Imagine the environment changing in exactly the pattern that cancels the oscillator’s own drift — the temperature nudging the crystal one way precisely as the crystal was about to wander the other. The two subtract, and your clock holds over almost perfectly. This is physically possible. It is also worth nothing, because you did not cause it and cannot repeat it.

The pathological room. Now imagine the opposite: every thermal excursion timed to push the frequency the same direction, every effect adding rather than cancelling, right up to the limits the datasheet allows. The clock drifts to its specified worst case. That is what the specification is for — it is the promise that even this room cannot do worse.

Every test you will ever run lands between those two. Which means a holdover measurement is a sample of one environment on one day, not a bound — and it is a sample drawn from the kind end of the range, because real rooms are far closer to lucky than to pathological.

What an honest specification looks like

Our own rule, arrived at after trying to write the other kind:

We do not promise a fixed holdover budget. We report the growing uncertainty and let whoever depends on it decide their own tolerance.

That is a harder thing to put on a datasheet and a much more useful thing to receive. It also matches how the rest of this site treats uncertainty — a number without its error bar is an assertion, not a measurement.

The protocol world has the same instinct built in. PTP carries a clockClass field precisely so a grandmaster can announce I have lost my reference and my confidence is degrading, and downstream clocks can decide for themselves whether to keep following it. A holdover design that never tells anybody it is in holdover has solved the easy half of the problem.

How to measure your own

Worth doing — but for what it tells you about your room, not as a replacement for the specification. You are measuring the environment your clock lives in, using the clock as the instrument.

1. Let it discipline properly first. Holdover performance depends on the loop having learned the frequency offset well, so a clock that has been locked for an hour will hold over worse than one locked for a day.
2. Disconnect the antenna, and keep measuring. Compare against a second source you have not disturbed — another clock, another receiver, anything independent.
3. Plot the error against elapsed time, not against a pass/fail line. The shape tells you which term dominates: roughly linear growth means frequency offset, and a curve that bends means the frequency itself is moving, which means temperature.
4. Do it twice — once with the room quiet and once with it not. Run it again during the part of the day when the HVAC works hardest. If the two curves differ substantially, you have found your real limit and it is not the oscillator.
5. Then pick your threshold and read the answer off the plot — as a typical figure for your site, alongside the datasheet’s worst case rather than instead of it. The gap between the two is the size of the margin your room is currently donating, and the room can stop donating it at any time.

The benchmarking page covers the measurement side of this in more detail. The point here is that holdover is one of the few clock behaviours you can watch for yourself with equipment you already own — and that watching it teaches you about your building at least as much as about your clock.

The short version

• Holdover is not free-running. The loop already removed the crystal’s frequency error; what you are left with is its drift, which is a much smaller number and the reason holdover works at all.
• A holdover figure with no threshold attached means nothing. Twenty-four hours to 1 ms and twenty-four hours to 100 ns are different products. Ask to what, and on which oscillator.
• The limit is usually your room, not your crystal. Temperature moves an oscillator faster than it would ever wander alone, so a stable room often buys more than a better part. Find out whether the air conditioning cycles before you price a rubidium.
• Quote the specification, never your own test. Every test lands somewhere between a room that cancels the drift by luck and a room that drives it to the datasheet limit — and real rooms sit near the lucky end. Beating the spec means your room was kind, which it will be right up until it isn’t.
• Measure anyway, to learn your building. The gap between your result and the worst case is the margin your room is currently donating. It can stop donating it at any time.

Where to go next

• What makes an accurate GNSS timing receiver? — the reference input that decides whether your oscillator is even in the loop.
• Questions to ask a clock vendor — question five is the holdover one, and this page is its long form.
• Ways to get time into a datacenter — the argument for having a second source, which is the other answer to losing the first.