Topics In Timekeeping · Measuring Time

Comparing distant clocks

Updated Aug 12, 2026 • UTC, GNSS, timing, metrology

Skip the details — take me to the bottom line ↓

Handing time out across your own estate is one problem, and the protocols page is about that one: you own both ends, you own the wire, and one end is unambiguously the source.

This is the other problem. Two clocks, a continent apart, owned by different people, and neither one is the source for the other. You want to know how far apart they are. There is no cable, and there is not going to be one.

If the first problem is a LAN, this is the WAN — and as with networking, the techniques that work over the long haul look almost nothing like the ones that work in a building.

Two jobs that use the same techniques

Worth separating up front, because the literature is written for one of them and most readers of this site want the other.

Peer comparison. Two national laboratories compare their clocks. Neither is right, neither is steering to the other, and the output is simply a number — [UTC(NIST) − UTC(PTB)] — with no instruction attached. This is what BIPM’s network is for and what every paper on the subject is written about.

Asymmetric sync. One end is a national laboratory and the other end is you. The laboratory is not adjusting anything; you are. The output is not a result, it is a correction, and what you want from it is to pull your clock into line and keep it there.

The techniques are identical. What differs is what you do with the answer — and that difference decides how much the latency below matters, which is the question that separates a one-time check from a control loop.

The central bargain: a third clock, and its error

With no wire between you, the only thing you and the distant laboratory have in common is a third clock that you can both see — an atomic clock in a satellite passing overhead.

That is the bargain, and it comes with a bill. Measuring against a third clock drags that clock’s error into your answer. So every technique on this page is a different way of removing it again.

Write down what your receiver actually records when it timestamps a satellite signal, and the shape of the problem is immediate:

what your receiver records  =   geometry
                              + your_clock_error
                              − satellite_clock_error
                              + atmosphere_delay
                              + noise

Those are all terms of one sum, and each has a different status:

One term is the answer. One term is in the way, and it is far larger than the thing you are trying to measure. Every technique below is a different way of removing satellite_clock_error from that sum. Once you see that, the field collapses into three options.

Common view: remove it with a second measurement

Have a second station watch the same satellite at the same instant. It records the same satellite_clock_error you did. Subtract the two records and that term cancels exactly — not modelled, not estimated, gone. What is left is the difference between the clock at your end and the clock at theirs.

It is a beautiful idea, and its beauty is that it needs nothing else. No correction stream, no internet, no subscription, nobody’s analysis to trust. Two receivers, a shared satellite, and arithmetic. That is why it could be built in the 1980s, and why it carried international timekeeping for two decades.

And if the far end’s clock is a national laboratory’s realization of UTC, the answer lands directly on UTC(NIST) or UTC(USNO) — a named timescale that somebody publishes, which turns out to matter more than anything else here.

The measurements are exchanged in a format called CGGTTS, which is worth a glance if only because its header states every delay in the chain.

This is the one technique on the page you can buy off the shelf. NIST sells it as TMAS — their receiver at your site, their calibration at both ends, their report at the end of it. Wherever this page weighs common view against the alternatives, TMAS is the concrete thing being weighed.

Then why has BIPM stopped using it?

Because the error it was invented to remove no longer exists. None of what follows makes common view a bad technique — there is a real case for it, and it closes this page — but the case has to be made against the evidence rather than instead of it.

BIPM’s own 2006 working document to the CCTF puts it on one axis, and this is the single most clarifying thing I found while writing this page:

Selective Availability was the deliberate dither the US applied to GPS satellite clocks, worth tens of nanoseconds. Common view removed it perfectly, which made common view worth a great deal. SA was switched off in May 2000.

Then the second half of the story: GNSS Analysis Centers — thirteen of them, listed by the IGS, including CNES, JPL and the U.S. Naval Observatory — now produce precise orbit and clock correction streams that take the error in the GPS signal to about a nanosecond. At which point what common view removes is worth less than what it costs.

What it costs is the part people skip

Requiring the same satellite at the same instant is not free:

Disadvantages (especially long baselines): Observed satellite number reduced; Low satellites, low S/N ratio; Multi-Bridge System of TAI Network.

You throw away every satellite the far end cannot see, and you are pushed toward the low-elevation ones you can both barely reach — which are exactly the satellites with the worst signal-to-noise and the most atmosphere in the way. The longer the baseline, the worse the deal.

BIPM measured it, and it is worth being precise about what they measured, because it is not signal-to-noise. Over eight months they compared each GPS link against an independent and more accurate link on the same pair of laboratories — two-way satellite transfer, or PPP — and took the scatter of the difference, in nanoseconds. That scatter is the GPS link’s own noise. Then they asked how much it shrank when the same data was processed all-in-view instead of common view:

Nothing at 600 km, a third at 10,000. Which is the same sentence as common view only removes what both ends genuinely share, written in numbers. Their stated mechanism is the obvious one: the number of satellites and epochs you get to use, and the quality of the ones you are left with.

All-in-view: the first fix, and still in service

(Not pictured above — it is the middle step, and the figure shows where the subject started and where it ended up.)

All-in-view keeps the same code measurements common view used — the same pseudoranges, from the same receivers, needing no new hardware — and simply drops the simultaneity rule. Each station uses every satellite it can see, solves its own offset against the constellation’s timescale using a GNSS Analysis Center’s precise correction stream, and only then are the two results differenced.

BIPM switched TAI links to it in September 2006, and their pitch was that it cost nothing to adopt: “improved TAI time transfer stability without any new investment — no hardware updating required.” The only disadvantage they listed was “more rigorous data processing than CV.”

PPP time transfer: remove the model instead

The last step adds the carrier phase — a far quieter measurement than the code, and the reason this technique is a factor of two better than the one above.

Each station runs its own PPP solution against the same correction stream, and the two solutions are then differenced. The stream’s datum — the arbitrary constant every satellite clock in it is offset by — appears in both solutions and cancels. BIPM has used it for UTC since 2009.

The receipts, from a file we download every month

Circular T Section 5 lists the technique for every link used to compute TAI. For issue 462, June 2026:

Not one common-view link, out of 86. And that is not a quirk of naming: the Explanatory supplement to Circular T defines the codes, and exactly one of them is common view —

GLN MC for GLONASS common-view multi-channel C/A data

— a GLONASS technique that no link used. Every GPS code in BIPM’s current vocabulary is all-in-view or PPP.

Read the uncertainty column and the ladder is plain: PPP links are 0.3 ns stable, dual-frequency code links 0.7 ns, single-frequency code links 1.5 to 3 ns. A factor of two to ten, for the same antennas on the same roofs.

How fast does any of this go?

The honest headline: none of these techniques is real-time, and the fastest of them is a ten-minute batch. That is not a limitation anyone has failed to fix. It is what the techniques are.

TMAS’s ten minutes is close to the practical floor for a published comparison, and it is worth understanding why rather than hoping for better. Every technique here works by averaging: a single epoch of code measurement is nanoseconds of noise, and you need minutes of it before the number means anything. Then you have to wait for the far end’s data to exist and arrive. Neither of those shortens much.

So: initial sync, or continuous discipline?

Both, but not the way a PTP grandmaster does it. The distinction that matters is the one between the two ways a clock can be wrong.

As a one-time check, it is excellent — and this is the obvious use. Stand up a clock, run a link for a few days, find out where you actually are.

As a continuous loop, it works for frequency and not for the seconds. Ten minutes of latency is hopeless for chasing a clock that jumps, but it is perfectly adequate for steering a rate, because a good oscillator’s frequency does not change meaningfully in ten minutes. This is exactly how a national laboratory uses its links: nobody is jerking UTC(NIST) around every ten minutes; they are nudging its rate over days.

Doing it with NIST at one end

Everything above is written the way the field writes it: two peers. Here is the asymmetric version, concretely, with a national laboratory at one end and you at the other.

Common view with NIST is what TMAS sells. NIST installs a receiver at your site, takes the PPS from your clock, compares against UTC(NIST), and reports every ten minutes. Their end is calibrated, yours is calibrated by them, and you get a report. It is the turnkey answer.

PPP time transfer with NIST you can assemble yourself, because NIST’s observations are public: their IGS station runs on UTC(NIST) itself, and its raw RINEX is anonymously downloadable. Run your PPP solution and theirs against the same correction stream, difference them, and you have the same measurement TMAS makes — by the technique BIPM prefers, without any baseline penalty, at no cost.

Free of charge is not free of obligation, though, and the distinction is the whole of the companion page. What you will not have is a calibrated end, which means you get frequency at full accuracy and no defensible time offset at all. We ran exactly this and published the numbers — including [UTC(USNO) − UTC(NIST)] computed from public observations, and the one number in that table we could not claim.

So what is your answer referenced to?

This is the part that took me longest to see, and it is the bottom band of the figure.

A PPP solution of the ordinary kind — one station, one correction stream, solve for your clock — gives you an excellent number referenced to that stream’s datum. The datum is stable and perfectly serviceable. It is also unpublished, uncertified, and appears in no document anybody outside that GNSS Analysis Center is obliged to accept. Your traceability chain stops there.

Difference two PPP solutions and the datum cancels. What you are left with is your clock against UTC(NIST) — which appears in Circular T Section 1 every month, with a published [UTC − UTC(NIST)] and a stated uncertainty. Your traceability chain does not stop; it continues, through NIST, to UTC itself.

So the anchor is not tighter in the sense of quieter. It is tighter in the sense that it connects to something. You trade a private zero for a public one, and traceability is precisely the business of public zeros.

Being fair to common view

Here is that case, as promised. A page that left it out would be selling something.

• The cancellation is exact. No model, no correction stream, no assumption. There is an honesty to that which the alternatives do not have.
• It needs nothing you have to subscribe to. In an outage, in a lab with no internet, on hardware from 1995, it still works.
• It is thoroughly standardized. CGGTTS is a stable, documented format with decades of continuity behind it, and continuity is worth real money in metrology.
• Short baselines lose almost nothing. BIPM measured ~0 % gain at 700 km. If your reference is regional rather than continental, the case against is much weaker.
• And what a service like TMAS sells is not the technique anyway. It sells a calibrated end of the link, a ten-minute feed, and a report with NIST’s uncertainty on it. Those would be worth buying wrapped around any technique.

If somebody is selling you common view

Three questions, in the spirit of the vendor questions page:

1. “What is my baseline to your reference, and what does the technique cost me at that distance?” Under a thousand kilometers, very little. Across an ocean, ask for numbers.
2. “Single-frequency or dual?” The deployed hardware matters more than the technique. A single-frequency receiver models the atmosphere rather than measuring it, and over long baselines that is the dominant term.
3. “Is this what you use for your own link into TAI?” For NIST the answer is on the public record and it is no. That is not a gotcha — it is a way of asking what the technique is being chosen for, which is usually continuity, calibration, and a report rather than performance.

What to take away

• Pick the technique on its merits, and know it barely matters. All three remove the satellite’s clock error; what separates them is what they cost you in satellites, in noise, and in how far apart the two ends are.
• Common view is not obsolete, it is superseded. The error it removes perfectly stopped being the largest one when Selective Availability went away. Under about a thousand kilometres it still loses you almost nothing.
• Baseline is the deciding number. BIPM measured ~0 % gain from switching at 700 km and ~35 % at 10,000 km. If your reference is regional, most of the argument against common view does not apply to you.
• None of this is real-time and none of it will be. Ten minutes is close to the floor for a published comparison, because every technique works by averaging. Use a link to steer a rate, and let your own oscillator carry the seconds in between.
• What your answer is referenced to matters more than how quiet it is. A correction stream’s datum is stable, private and certified by nobody. Difference two solutions and you land on UTC(NIST), which appears in Circular T every month with a published uncertainty. You trade a private zero for a public one, and that is the whole business of traceability.

Where to go next

• Can I build my own link to UTC(NIST)? — this page’s techniques actually run, on public data, with our own numbers and the wall they hit.
• Distributing time: the protocols — the other problem, the one where you own the wire.
• What “traceable to UTC” actually requires — why a public zero is worth more than a quiet one.