A clock drifting at 200 parts per million and corrected every 30 seconds can be ε = 6 ms out of true at the worst moment, and two such clocks can differ by 2ε = 12 ms. Any two events whose true separation is smaller than that window — say 5 ms — cannot be ordered by their timestamps at all, in either direction. Waiting 2ε before making a commit visible converts the bound into an order, and costs 12 ms per dependent commit to do it.
Core ideas
An exact unit conversion, a factor of two, and the price of turning an error bound into an ordering.
A drift of 200 ppm means the clock gains or loses 200 microseconds every second, so over a 30-second correction interval it can be 6000 microseconds — 6 ms — away from true at the moment just before the next correction. The conversion is exact and it is the only arithmetic in the lesson; everything else is a consequence of it.
One clock may be up to ε fast and another up to ε slow, so the difference between two readings of the same instant can be as much as 2ε. That 2ε is the uncertainty window, and it is the quantity that matters, because ordering two events always means comparing two clocks.
If two events are truly 5 ms apart and the window is 12 ms, the timestamps can say the first came first, the second came first, or that they were simultaneous, and all three readings are consistent with the same true order. A commit-wait of 2ε — hold the result until the window has passed — restores an ordering, and its cost is 2ε per commit that something else must see.
The material
The exact conversion from a drift rate, why the window is twice one clock's error, and what it costs to get an ordering back.
Drift is the rate at which a clock departs from true time, quoted in parts per million. Between corrections at interval I, a clock accumulates an error of up to ε = drift × I. Two clocks may be out in opposite directions, so the uncertainty window within which their readings cannot be compared is 2ε.
Time synchronisation does not make clocks equal. It corrects them periodically, which bounds the error and restarts the accumulation; between corrections the drift resumes at the same rate. A cluster running a time daemon has clocks within a window, not clocks that agree, and the size of that window is a design input rather than a detail.
The window is linear in both inputs, which makes the two levers obvious and their prices very different. Halving the drift means better oscillators in every machine; halving the interval means twice the synchronisation traffic and is nearly free. That asymmetry is why tight-clock systems synchronise aggressively rather than buying exotic hardware, up to the point where the network round trip becomes the floor on the error.
This is why a timestamp comparison is not an ordering primitive. It answers instantly and it answers wrongly whenever the answer was close, which is exactly the case anyone bothers to ask about — two events far apart in time are rarely in dispute. The failure is silent, it is data-dependent, and it disappears on a single machine, which is where the code was tested.
Hold each commit for 2ε = 12 ms before making it visible and the window is guaranteed to have closed, so any commit a reader can see really did happen before anything it observes afterwards. The price is 12 ms added to every dependent commit: a chain of commits that must each be visible before the next begins is capped near 1000/12 ≈ 83 a second, however fast the hardware is. Halve the sync interval and that cap doubles, which is the direct reason such systems care about how often their clocks are corrected.
Two honest positions follow and they are both defensible. Either carry the uncertainty explicitly — a timestamp is an interval, not a point, and you wait when the intervals overlap — or do not use physical clocks for ordering at all and use the counters of the previous two lessons, which cost messages instead of milliseconds. What is not defensible is comparing two raw timestamps from two machines and treating the result as an order.
Interactive
ε, the 2ε window, and the order a wall clock cannot decide
Method
Two multiplications and a comparison. The discipline is remembering the factor of two and never dropping the units.
Parts per million already is microseconds per second, so there is nothing to convert — 200 ppm is 200 µs/s. Writing the units down is what keeps the next step honest.
ε = drift × interval, the worst-case error of one clock just before its next correction. At 200 ppm and 30 seconds, 6000 µs = 6 ms. This is a bound, not a typical value; typical is better and the bound is what you can rely on.
2ε is the window. Forgetting the factor of two is the commonest error here and it halves a safety margin, which is the direction that produces incidents rather than slowdowns.
If the true gap between the events you must order is smaller than 2ε, timestamps cannot order them and you need either a commit-wait of 2ε, a tighter window, or a logical clock. Say which of the three you chose.
Two nodes, each with a clock specified at 200 parts per million and corrected every 30 seconds. Two events happen on them, truly 5 ms apart, and a piece of code is about to order them by comparing timestamps.
The third line of the repairs is the one most systems take, and it is worth seeing why: shrinking the interval from 30 seconds to 1 second shrinks the window by a factor of thirty, from 12 ms to 400 µs, and the 5 ms gap is then comfortably outside it. Synchronisation traffic is cheap and oscillators are not.
The commit-wait line is the one that shows up as a throughput number in a design review. 83 dependent commits a second is a real ceiling, and it is set entirely by 2ε — which means a team that wants more of them is really asking for a tighter clock, whether or not anybody has said so.
For a faded rehearsal, the hardware is replaced with clocks specified at 50 ppm and the sync interval is left at 30 seconds. The supplied first move is ε = 50 × 30 = 1500 µs. Compute 2ε, say whether the 5 ms gap is now resolvable, work out the commit-wait ceiling at that window, and check all three in the lab.
You should be able to convert parts per million into microseconds per second, compute ε and 2ε for any drift and interval, decide whether a given separation is resolvable, price a commit-wait in throughput, and name the three repairs with their costs.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.