Matching acquisition and distribution
Getting accurate time into a datacenter is two problems, not one.
Acquisition is getting time into the building from somewhere authoritative — a GNSS antenna on the roof, a fiber from a national lab, a service delivered over a dedicated link, NTP over the internet.
Distribution is getting that time from wherever it arrives to every host that needs it — the switches, the protocol, the cabling, the network asymmetries.
These are not in competition. You do not choose between them, you do not trade one against the other, and neither is more important. Both have to be solved, and your result is what the worse of the two allows.
Why they cannot be considered separately
Because the errors add, and once added they cannot be pulled apart again.
A host reading 60 ns from UTC does not come with a breakdown of how much of that was the antenna survey, the feedline, the grandmaster, the switch chain, and the last cable to the rack. You get one number. The contributions are gone.
Which means the useful question is never “how good is my grandmaster?” but “how good is the chain?” — and a chain has no more accuracy than its worst link.
Precision acquisition feeding sloppy distribution is money spent on accuracy that never reaches a host. Sloppy acquisition feeding precision distribution is money spent delivering an error faithfully to every rack in the building.
Whichever is worse sets what you actually have. The better one is paying for performance it cannot deliver.
The matching table
Each row pairs an acquisition method with a transfer method of comparable capability. Read across, not down — the point is that both columns have to arrive at the same place. The table is from The Last Nanoseconds to UTC.
| Time acquisition | Time transfer | Accuracy / precision |
|---|---|---|
| Internet | NTP | millisecond |
| GNSS SPP | PTP | ~15 ns |
| GNSS Float PPP | PPS | ~1 ns |
| GNSS PPP-AR | White Rabbit | sub-nanosecond |
Two things fall out of reading it as pairs.
Buying up one column alone buys you nothing. Pair GNSS PPP-AR with NTP and you have spent real money establishing a position solution good to sub-nanosecond, then delivered it over a protocol good to milliseconds. The result is milliseconds.
The acquisition column is the harder one. Every row after the first requires a better GNSS solution — SPP, then float PPP, then PPP-AR — and each step there costs more work than the corresponding step in the transfer column.
Which side is actually limiting you
Usually acquisition, and by a wide margin. Here is a real campus:
Time can be moved across that entire campus — half a mile, building to building — to within 200 picoseconds. Getting UTC into the campus in the first place is good to about ±15 nanoseconds RMS.
That is the state of the art in miniature: distribution has run well ahead of acquisition. Moving time around a site is close to a solved problem. Knowing what time it is, to the accuracy the distribution could carry, is not.
Which is worth knowing before you spend anything. If your distribution is already seventy-five times better than your source, another switch upgrade changes nothing at all.
What matching looks like in practice
Check the whole path before improving any part of it. The instinct on discovering a 100 ns error is to buy a better grandmaster. Frequently the grandmaster was already ten times better than the switch chain carrying its output.
Errors in distribution are not only random. It is tempting to think of acquisition as the source of bias and distribution as the source of jitter. Not so — an uncompensated pulse-per-second cable, an asymmetric network path, a switch that delays one direction more than the other, all put a fixed offset into distributed time. Distribution can be the dominant contributor to how far you sit from UTC.
Both halves have uncompensated regions. This is the thread that connects the two pages: some delays are measured and subtracted by the protocol, and some are not. Knowing which is which decides where a mistake costs you nothing and where it costs you permanently.
Where to go next
- Acquiring time — the ways time gets into a building, and why GNSS so often lands in the sweet spot.
- Distributing time — the protocols, what each is capable of, and which of them compensate for path length.