Time Distribution Protocols
Three names for the same job, depending on who you ask:
- Time distribution — what datacenter engineers usually call it.
- Clock sync — what application people usually call it.
- Time transfer — the metrologist’s term, and the one you will meet in the literature and in national lab publications.
They mean the same thing: moving time from where you have it to where you need it, and keeping track of what the journey cost.
The protocols
| Protocol | Standard | Typical accuracy | Compensates for path delay? |
|---|---|---|---|
| NTP over the internet | RFC 5905 | milliseconds | Yes — round-trip estimate, assumes symmetry |
| NTP on a LAN | RFC 5905 | hundreds of µs to ms | Yes — same mechanism, less jitter |
| NTS | RFC 8915 | as NTP | Yes — NTP, with authentication added |
| PTP, software timestamps | IEEE 1588-2008 | tens of µs | Yes — measured, but timestamps taken late |
| PTP, hardware timestamps | IEEE 1588-2008 | sub-µs to tens of ns | Yes — measured at the wire |
| White Rabbit | IEEE 1588-2019 High Accuracy profile | sub-nanosecond | Yes — and it measures asymmetry too |
| PPS | — | ~50 ps to 1 ns | No |
Links out, because each of these is documented far better elsewhere than a page of this length could manage: NTP, NTS (RFC 8915), PTP / IEEE 1588, White Rabbit.
The column that matters most
Which protocols compensate for the length of the wire by measuring its delay, and which leave it to you.
NTP, PTP, and White Rabbit all measure the path delay. They exchange timestamps in both directions, work out the delay, and subtract it. Add fifty meters of fiber and they notice the delay, adjust, and carry on. Path length and delays are their problems, not yours.
PPS does not. A pulse-per-second signal is a wire with an edge on it. There is no exchange, no round trip, nothing to measure with — the pulse arrives when it arrives, and every nanosecond the cable adds is a nanosecond of error you own.
That is the same distinction the feedline page is built on, and it is worth carrying between them: a delay that is measured is a nuisance, and a delay that is assumed is a permanent offset.
NTP and PTP (IEEE 1588-2008) compute path delay from a round trip and split it in half, which is only correct if the two directions take equally long. An asymmetric path — a different route each way, a queue that fills in one direction — puts half the asymmetry straight into your offset, and no amount of protocol conformance detects it.
White Rabbit is the exception, and the way it gets there is worth knowing — including one thing it is commonly given credit for that it does not deserve.
1588-2008 already had somewhere to put asymmetry. There is a
delayAsymmetry correction in the standard, and always was. What the standard
has never given you is a way to find out what to write in it. A field for a
quantity is not a method for determining it, and an unmeasured asymmetry
correction defaults to zero — which is exactly the assumption it was supposed to
relax.
White Rabbit’s contribution is the measurement, achieved at the physical layer: it runs both directions down a single fiber strand on different wavelengths instead of over a duplex pair. Two fibers are never quite the same length; one fiber cannot disagree with itself. What asymmetry remains comes from the two wavelengths propagating at slightly different speeds — a calculable quantity rather than an unknown one.
Its techniques were subsequently folded into IEEE 1588 as the High Accuracy profile of 1588-2019, which is the accurate way to cite it. White Rabbit predates that standard by roughly a decade; the profile documents what White Rabbit was already doing rather than the other way round.
PPS is barely a protocol, and belongs here anyway
A pulse per second carries no information beyond now. It does not say which second it is, cannot be routed, and needs something else alongside it to supply the numbering.
It earns a place in this table because it does the same job — moving a moment in time from one box to another — and because at the accurate end of the range it is what everything else falls back on. The last hop into a grandmaster, or between a reference and a counter on a bench, is very often a PPS cable.
A GPS network clock speaks the protocols above. That is what it is for — it exists to turn an antenna into NTP and PTP on your network.
A GNSS receiver module speaks none of them. It emits a PPS and a serial stream, and everything on this page is work you would be taking on yourself. If you are holding a module and wondering which protocol it supports, the answer is that supplying one is your job.
The trade is stark: no protocol overhead and no timestamp exchange, which makes it very good, and no path compensation whatsoever, which makes it very unforgiving.
PPS is better than it is usually given credit for
It is often quoted as good to “about a nanosecond”, and that undersells it. In PePPAR-Fix testing we have repeatedly measured the single-shot resolution of a TAPR TICC at 60 ps or a little better — which is an existence proof that the pulse itself is not what limits you at the nanosecond level.
Worth being careful about what that number is, since this site makes a point of the distinction: 60 ps is a resolution figure, not an accuracy one. It says the edges can be seen that finely. Turning that into accuracy still requires the cable delay to be calibrated, because nothing in PPS will do it for you.
Given a calibrated cable and a well-behaved trigger, 50 ps to 1 ns is a fair range to expect. The low end takes care; the high end is what you get for free.
The range each protocol covers
Two features of that chart are worth pointing at.
The bars fade rather than stop. Where a protocol runs out is not a property of the protocol — it depends on timestamping hardware, network topology, and how much effort you are willing to spend. A hard right edge would be a number somebody could argue with, and the argument would not be productive.
PPS starts short of the left edge, marked No Epoch — using epoch in its origin sense, a fixed point to count from. Every other bar can tell you which second it is. PPS cannot: it marks a moment without naming it. It is remarkable at saying now and incapable of saying when, which is why it always travels alongside something else that supplies the numbering.
PPS and White Rabbit both reach the right-hand end. They get there very differently — one by being a wire with nothing in the way, the other by measuring everything in the way very carefully — but the achievable floor is similar.
NTS: NTP with the spoofing fixed
Network Time Security (RFC 8915) is NTP with authentication. Same protocol, same accuracy, same servers — with cryptographic assurance that the time came from who it claims to have come from and was not altered in transit.
That matters because plain NTP is trivially spoofable. Anyone who can inject packets can hand your fleet whatever time they like, and nothing in NTP objects. NTS closes that, and it costs nothing: the specification is open, public NTS servers exist, and support is in the common implementations.
There is no accuracy argument here — NTS is not more accurate than NTP. It is the same accuracy that you can trust, which is a different axis and frequently the one that matters. See acquiring time for the same question on the GNSS side, where the answer is OSNMA.
Choosing
The honest guidance is short. Work out what you need from matching acquisition and distribution, then take the least complicated protocol that reaches it. Every step up this table costs hardware, configuration, and people who understand it.