The Last Nanoseconds to UTC
I set out to research the limits of clock sync precision — effectively chasing the last nanoseconds to UTC.
Is sub-nanosecond UTC sync possible? Literally, no. Practically, yes.
That sounds like a dodge, and it isn’t. The gap between those two answers is the most useful thing I learned, and it turns on a distinction that’s easy to skate past: agreeing with another clock is not the same as being right about UTC.
I gave this talk at the London and New York STAC Summits, to audiences who care about this for financial markets.
Why You Literally Cannot Get Below About 5 ns
Two things stand in the way, and neither is about your equipment.
The constellations themselves sit about 5 ns from UTC. Even the best GNSS
constellations have a standard deviation around 5 ns relative to UTC. That isn’t
a rumour — it’s published. Look for sigma_GPS in a recent
Circular-T from BIPM
and check me on it.
UTC doesn’t exist in real time. A national lab like NIST has atomic clocks that do far better than 5 ns, but UTC is a virtual timescale, computed after the fact from contributions around the world.
The mechanism is worth spelling out, because it’s the part that surprises people. Each country’s time lab watches the satellites, compares what comes down against its own earthbound clocks, and reports the differences to the BIPM in Paris. Then — weeks to months later — the BIPM publishes what UTC was.
There is no wire you can plug into that carries UTC as it happens. As I put it in the talk: everybody else on Earth is predicting UTC. The BIPM is defining it, in arrears.
So if you’re getting time from GNSS rather than from a national lab, you cannot literally be closer than about 5 ns to UTC. That ceiling is structural, and no equipment budget moves it.
Why You Can Practically Do Far Better
Now the interesting part.
In my homelab, two high-quality GNSS receiver modules — u-blox F9T — agreed with each other to 550 picoseconds over half a day, while each wandered 6 to 7 nanoseconds against GPS.
Two conditions made that number possible, and I skipped past both in the talk for lack of time. You need to track a single constellation, because the constellations don’t agree with each other to better than about 5 ns. And you need a dual-frequency receiver, so the ionosphere can be measured out rather than modelled. Take either away and the result doesn’t hold.
If a constellation is running 5 ns ahead of UTC, every receiver tracking it is 5 ns ahead of UTC too — together. The shared error cancels between them. Two clocks can agree sub-nanosecond while both are wrong about UTC by an order of magnitude more than that.
Whether that’s good news depends entirely on your question.
If you need to prove to a regulator that a timestamp is within some tolerance of UTC, the 5 ns floor is your problem and no amount of care in the lab removes it.
But if what you actually need is for two machines to agree on the order of events — which is what most people in markets are really asking — then the constellation’s offset from UTC is a common-mode error that cancels. You care about the 550 ps, not the 5 ns.
Most of the confusion I’ve seen in this area comes from conflating those two questions.
The Part That Bites in a Datacenter
All of the above assumes you can put an antenna where it needs to be. In a datacenter you usually can’t, and this is where the theory meets a roof.
The roof blocks the sky, so the antenna goes on top of it — either one you install or one the facility provides. Either way, as a tenant you are likely missing two numbers: where the antenna actually is, and how long the feedline is that runs from it down to your rack.
They cost you time for entirely different reasons, so they are worth taking apart separately.
The solution is for a point inside the antenna
GNSS doesn’t solve for the time at your receiver. It solves for the time at the antenna phase center — a spot several centimeters up inside the antenna housing, invisible from outside, and in a different place for every model. It is the antenna phase center’s position that goes into the equations, not the mounting bracket’s.
Get that position wrong and the error lands directly in your clock. Time error is proportional to position error, though the constant relating the two is not simply the speed of light — it depends on which direction you are wrong in, and on where the satellites happen to be while you are wrong. The bound is the part worth carrying around: a foot of position error costs at most about a nanosecond, and in practice usually less.
It is a static offset. It does not average away, and no amount of patience improves it.
Nothing measures the feedline for you
The second number is the cable, and it is the one people find surprising.
Signal travels more slowly down coax than through free space — typically around two-thirds to four-fifths of c — so a foot of feedline costs you rather more than a foot of free space, call it 1.2 to 1.5 nanoseconds. A run from a rooftop antenna to a rack inside can easily be a hundred feet of it.
Now, the reason this is a surprise rather than a nuisance. Inside the distribution network, NTP, PTP and White Rabbit all measure the delay between nodes and subtract it, which is why time looks the same everywhere downstream. That machinery is genuinely good, and it teaches people that delay is a solved problem.
It stops at the receiver. The antenna feedline — and the pulse-per-second wiring on the other side of the receiver — sit outside the compensated region entirely. Nothing on your network measures them, because nothing on your network can see them.
What Actually Removes Them
Configuration, not measurement. The antenna phase center’s position and the feedline’s delay are numbers you configure into the GNSS receiver, which then corrects for both. Get them right and they disappear.
Which is why not knowing them is the problem, rather than an inconvenience. Leave either at a default, or at a guess, and you are left with a constant, unknown offset in every timestamp the receiver produces. Both are errors a beautiful clock cannot fix — oscillator quality does nothing for either — and that is what makes this a datacenter problem rather than a timekeeping one.
What I Haven’t Tested Yet
This is the state of GNSS clock sync as I see it in late 2025. Two developments look like they could move the floor and I haven’t put either on the bench:
- Galileo HAS, which may bring their standard deviation down.
- Fugro AtomiChron, which promises sub-nanosecond sync to their own traceable reference timescale.
The Slides
View the presentation on GitHub, or download it for offline viewing. The measurement tools are in f9tResearch.
My presentation style is heavy on visuals and light on bullets, with the key points carried by narration — so the PDF necessarily gives you less than the room got. The compensation runs the other way at the end: the live audiences never had enough screen time to sit with the final Takeaways and Best Practices slides, and you do.
Having established what’s possible, the obvious next question was whether I could build one. That became a sequel.