Accurately measuring elapsed time
A clock bad enough that the internet’s most forgiving time protocol refuses to work with it will still measure a microsecond-scale interval to about a nanosecond.
That is the surprise, and it is not a trick. Short elapsed-time measurements are extraordinarily forgiving of bad clocks — so much so that the interesting question is usually not how good is my clock but am I measuring a duration or a moment, because the answers cost wildly different amounts.
A timescale defines three things: the duration of one tick, a time when the first tick happened, and a count of elapsed ticks since then.
Measuring a duration needs only the first and the last. You do not need to know what time it is to know how long something took — you need a tick of known length and something to count ticks with. No origin, no agreement with anybody else, no reference to UTC.
That makes elapsed time a fundamentally cheaper problem, and knowing when you have it rather than the expensive one saves real money.
Two independent ways for a clock to be wrong
Worth separating before going further, because they are genuinely different faults and people routinely say “the clock is off” meaning either one.
A clock can run fast or slow. Its ticks are the wrong length. This is a frequency error — the clock is off frequency — and it accumulates. A clock running slow falls further behind every hour it runs.
A clock can be ahead or behind. Its ticks are the right length but it started counting from the wrong place. This is an offset error, and it does not accumulate at all. A clock set three minutes fast that otherwise keeps perfect time is three minutes fast forever — no worse tomorrow than today.
These map exactly onto the two parameters relating any pair of timescales: frequency error is the slope, offset error is the intercept. A clock can have either, both, or neither, and the fixes are unrelated — you correct an offset by setting the clock once, and a frequency error by disciplining it continuously.
Measuring a short elapsed interval is insensitive to both kinds of error. The offset appears at the start and the end of the subtraction and cancels exactly. The frequency error contributes in proportion to a duration that is, by assumption, very short.
How forgiving, exactly
Consider a trader measuring the interval between a market data tick arriving and an order going out — say 2.5 µs.
Suppose the counter is off frequency by 1 part per million, which is poor by timing standards:
2.5 µs × 1 ppm = 2.5 picoseconds of error.
Two and a half picoseconds. Under a hundredth of a millimeter in distance terms. Meanwhile that same clock could be a full millisecond from UTC and this measurement would not notice, because the offset cancels in the subtraction.
How bad does a clock have to be before anyone objects?
NTP is the most error-tolerant of the common time distribution protocols, and it gives up on a host whose clock is off frequency by more than about 500 ppm — that is the ceiling on how much frequency correction it can apply.
500 ppm is an enormous frequency error: 0.05%. Put it in a wristwatch and
- it loses 43 seconds a day, and
- after a week you are five minutes late for everything.
Nobody would tolerate that watch. And yet, returning to the 2.5 µs tick-to-trade measurement:
2.5 µs × 500 ppm = 1.25 nanoseconds.
A clock so bad that the internet’s most forgiving time protocol refuses to work with it still measures a microsecond-scale interval to about a nanosecond. That gap is the whole argument of this page.
500 ppm is the hard bound on frequency correction. The capture range — how much error the discipline can pull in from a standing start — is narrower at longer poll intervals, roughly halving each time the poll doubles. So a host can sit inside the hard limit and still fail to discipline at a long poll.
Where the forgiveness runs out
Three places, worth naming because that is where the reasoning breaks:
Long intervals. Frequency error scales with duration. The same 1 ppm that costs 2.5 ps over 2.5 µs costs 86 ms over a day. Measure something long enough and you need a good oscillator after all.
Intervals measured by two different clocks. The cancellation depends on both timestamps coming from the same counter. Start on one clock and stop on another and you are measuring elapsed time plus the offset between two clocks — which is the expensive problem wearing a disguise.
Anything compared with somebody else’s record. A duration reported to a regulator or a counterparty has to be anchored to a shared timescale to mean anything to them, at which point you need the origin after all.
Which is the useful question
Before buying accuracy, work out which of these you actually have:
- How long did it take? — one clock, short interval, cheap.
- In what order did these happen? — several clocks that must agree with each other, moderately expensive.
- When exactly did this happen? — agreement with UTC, most expensive.
Organizations routinely buy the third when they needed the first. The questions to ask a vendor start here for exactly that reason.