Datacenter GNSS Time Best Practices
Skip the details — take me to the bottom line ↓
This is the closing slide of The Last Nanoseconds to UTC, unpacked. Eight practices, and the striking thing about them as a group is how little they cost. Almost none require better hardware. What they require is that somebody decides to do them, once, and writes down what they did.
They are also, mostly, defenses against error you would never otherwise see — which is why they read as fussy until the day something depends on them.
1. Run GNSS clocks in fixed-position mode, not survey-in
A receiver that keeps solving for its own position is solving four unknowns when it only has one. Survey the antenna properly, configure the answer, and let the receiver solve for time alone — it needs fewer satellites and gets a better answer.
The catch worth knowing: fixed position is only safe if the position is right and somebody notices when the antenna moves.
→ How to configure antenna position
2. Choose antenna sites with good sky view and few multipath reflections
The site is the one decision you cannot fix later with configuration. A wall beside the antenna reflects a signal that arrives late and pretends to be the real one, and it does so at the same time every day, which is precisely what averaging cannot remove.
Sky view and multipath are worth more attention than the receiver you bolt to the end of the cable.
3. Use a dual-band receiver and antenna
L1/L5 or L1/L2 — the point is two frequencies, not which two. A single-frequency receiver has to model the ionosphere; a dual-frequency one measures it. NIST put a number on the difference: over a long baseline, single-frequency measurements ranged up to 50 ns in a day where dual-frequency stayed within about 10.
It is the single biggest jump available, and it is a purchase decision rather than a configuration one — so it is worth getting right at order time.
→ What makes an accurate GNSS timing receiver?
4. Measure the antenna feedline and configure it in
Tens of meters of coax between a roof antenna and a rack receiver is tens of nanoseconds of delay that nothing in the system will mention. Measure it, or look it up from the cable’s velocity factor, and type the number in.
→ How to configure feedline length
All four are the same instruction wearing different clothes: find out the number, and configure it, rather than letting the equipment guess.
Every one of them fails silently. A wrong position, a wrong cable delay, a single-frequency receiver in a bad ionospheric hour — none raises an alarm, none degrades a status light, and all of them produce a confident, steady, wrong answer.
5. Defend against spoofing — use NTS to public servers, and ntpsec over ntpd
Accuracy and authenticity are different problems, and the second is easier to forget. A spoofed source can be exquisitely precise and completely wrong.
For network time, NTS
(RFC 8915) authenticates what NTP never did, and ntpsec is the implementation
to prefer over the traditional ntpd.
→ Keeping time on Proxmox with ntpsec
6. Check your clocks against something else you already have
Matching engine timestamps, application logs, a partner’s feed — anything carrying somebody else’s clock. Plot the minimum delta over intervals of a few thousand messages and watch that floor rather than the mean. The minimum is the luckiest message in the interval — no contention, nothing cold — so it strips out the variable delay and leaves the clock difference.
Average those minima over a few days and you have learned the physical floor; subtract it and what is left is your clock minus theirs, with alarm thresholds the stream taught you itself.
Then do it for streams that have nothing to do with each other. If all the minimums move together, it is your clock — nothing else could move unrelated counterparties at once. Keep a few weeks of it for the forensic question that arrives without warning.
→ The free second clock already arriving at your door
7. Use the symmetry of radio and fiber latency to check clocks across sites
Between two sites, the one-way delay each direction ought to be the same. How safe that assumption is depends entirely on the medium.
A radio path is genuinely reciprocal. Both directions cross the same air over the same distance, and whatever residual difference a duplex frequency split leaves is far below anything else in the chain. With matched full-duplex transceivers at each end, the asymmetry that remains lives in the equipment, not in the path — a much smaller and much more tractable problem.
A full-duplex fiber pair is two different pieces of glass, and they are not the same length. That is not a defect; it is how cable is made and spliced.
The arithmetic is worth doing slowly, because it lands on two different numbers and it is easy to quote the wrong one. The familiar rule of thumb is correct: one meter of fiber is about 5 ns of delay. But a two-way protocol measures the round trip and halves it, so one meter of length difference between the two directions arrives as about 2.4 ns of clock error — the protocol’s own halving, applied to an asymmetry it assumed was not there.
The 5 ns has not gone anywhere. Difference the two directions’ transit times directly and you measure the full ~5 ns, because that is the path asymmetry itself rather than the error it induces in a clock. Both numbers are right; they answer different questions, and the one to quote depends on whether you are describing the cable or the clock.
The same source treats keeping a pair within two meters as the mark of good cabling control — so a few nanoseconds of static asymmetry is the normal case, not the pathological one.
A single fiber running both directions is worse on this term, not better. It has to use a different wavelength each way, and the fiber’s index differs between them — about 0.34 ns/km in the C band and 0.39 ns/km in the L band, which is tens of nanoseconds across a hundred kilometers of otherwise identical glass.
If you have both between the same pair of sites, use the radio path to measure the fiber path’s asymmetry. Compare the two, and the difference is the fiber’s static offset — the number PTP would otherwise be silently wrong by.
This is BIPM’s calibration campaign in miniature: take the link you trust to be symmetric, co-locate it with the one you do not, and let it hand over its own accuracy. You inherit the radio path’s residual asymmetry as your floor, which is the honest price and a great deal better than assuming zero.
Once you know a path is symmetric, or have characterized its static asymmetry, any dynamic asymmetry you measure in the timestamps is not the network — it is one of your clocks. That turns an ordinary link into an instrument, using infrastructure you are already paying for.
8. Know which parts of your time distribution network are automatically delay-compensated
PTP measures network delay and compensates for it automatically. A raw PPS signal can do neither — it has no mechanism to measure its own delay and no field to carry a correction.
Where delay is not compensated automatically, you either compensate it by hand or you live with the error. And the manually-compensated links are almost always at the two ends — typically a PPS into the distribution network and a PPS back out of it — which is exactly where nobody is looking, because the automatic part in the middle is the part with the impressive specification.
→ Time distribution protocols · Matching acquisition and distribution
What the eight practices have in common
Read the eight together and two things stand out.
Almost none of them is about buying better equipment. One is a purchase decision; the rest are siting, measurement, configuration and checking. The common failure in datacenter timing is not cheap hardware — it is good hardware running on numbers nobody established.
Almost all of them defend against silence. A wrong position, an uncompensated cable, a spoofed source, a drifting clock nobody compares: none of these announces itself. The practices are not a route to a better number so much as a route to knowing your number, which is a different and more durable thing.
Where to go next
- Ways to get time into a datacenter — the decision that comes before any of these.
- Questions to ask a clock vendor — practice 3 is a purchase, and these are the questions around it.
- The Last Nanoseconds to UTC — the talk this list closes, with the measurements behind it.