Should I prioritize clock agreement or accuracy to UTC?

Usually you should not have to choose, and the question is a false one.

Almost everything that makes a clock estimate better makes it better on both counts at once. A surveyed antenna position, a measured feedline, a quieter oscillator, a shorter loop — none of these trade agreement against accuracy. They remove error, and removing error improves your offset from UTC and your spread across the clocks themselves.

The choice only becomes real at the end, when the cheap error is gone and what remains is a deliberate allocation. That is where the sentiment below comes from, and where it is exactly right.

Anyone who has run timing in a datacenter has heard it, and most have said it:

It’s more important that my clocks agree with each other than that they’re right.

Pressed for numbers, the same person will happily quantify the tradeoff:

I’d rather have my clocks off by 100 ns on average while agreeing to 10 ns, than have zero average error while only agreeing to 25 ns.

This is usually offered slightly sheepishly, as though it were a confession of low standards. It is not. It is a precise engineering preference, and for a great many datacenter applications it is the right one. What it lacks is the vocabulary to say so without sounding like an excuse — and a clear statement of what it costs, because it does cost something.

What they are actually saying

The two statements are not about the same quantity.

“Right” means the offset from UTC — a trueness claim about each clock individually, against an external reference.

“Agree” means the spread across your own clocks — how far they are from each other, which is a claim about dispersion and says nothing about where the group sits.

So the sentiment translates to: I will trade a common-mode error — one that hits every clock equally, so it never shows up in a comparison between them — for a smaller differential error. And the reason that is a good tradeoff is arithmetic rather than taste.

The tradeoff, in both languages. Top: the two sets of clocks as targets. Bottom: the same two as distributions, for readers who would rather see μ and σ. The left-hand option is worse against UTC and better at everything the application actually computes.

Why the 100 ns is free

Take the tradeoff at face value. Every clock is 100 ns late, and they agree with one another to 10 ns.

Now compute anything your application actually computes: the interval between two events, the order in which they happened, the latency from a market data tick to an order leaving. Each of those is a difference between two timestamps. Subtract, and the shared 100 ns cancels exactly.

It is not that the 100 ns is small. It is that it is common-mode, and every internal calculation you perform is a differential measurement that rejects it entirely. The error that survives the subtraction is the 10 ns of disagreement.

Run the other option and the survivor is 25 ns. By that measure the second configuration is two and a half times worse.

Put plainly: when you prioritize your clocks agreeing with each other over agreeing with UTC, you are prioritizing the correctness of elapsed-time measurements between your own clocks. For a great deal of trading and datacenter work that is exactly the right priority.

The boundary where it stops being free

Common-mode error cancels among your own clocks. It cancels only among them.

The moment a timestamp is compared with one that did not come from your clocks, the 100 ns stops cancelling and becomes the entire error. That happens at every edge of your estate:

  • a regulator reconciling your timestamps against a reference;
  • an exchange or counterparty comparing their record with yours;
  • another datacenter of your own, disciplined from a different source;
  • any measurement of one-way latency into or out of your estate.

So the sentiment is not wrong, it is scoped. It holds exactly as far as your estate does, and the scoping is worth making explicit, because the boundary is rarely where people assume — it is usually much closer than the building.

It is really a statement about distribution

Notice which half of the problem the preference is about.

Agreement among your own clocks is a property of how you distribute time from a common source: the switches, the protocol, the cabling, the asymmetries. Trueness against UTC is a property of how you acquire it: the antenna, the receiver, the survey, the feedline.

Someone saying “agreement matters more” is saying they will spend on distribution before acquisition. Given the trade above, and given that distribution errors are differential and acquisition errors are largely common-mode, that is the right order — until that boundary is crossed, at which point the spending they deferred is the whole of their error.

Saying it rigorously

The version to use when it matters:

Among a set of clocks fed from one source, common-mode offset cancels in every differential measurement, so the internal error is governed by their dispersion rather than by their offset from UTC. Only measurements crossing out of that set are exposed to the offset.

That says the same thing as the sheepish version, commits to where it stops being true, and does not sound like an apology.