An NTP client shows stratum 3, root delay 0.8 ms and root dispersion 1.2 ms; what error bound do these give, and how did they accumulate?

## Two fields that summarise the whole path Every NTPv4 header carries two 32-bit values in **NTP short format** (16 bits of seconds, 16 bits of fraction, a resolution of about 15 microseconds): - **`Root Delay`** - RFC 5905: "total round-trip delay to the reference clock". - **`Root Dispersion`** - "total dispersion to the reference clock". **Dispersion** is NTP's name for the maximum error inherent in a measurement: clock-reading precision, plus growth at the **frequency tolerance PHI**, which RFC 5905 sets at 15 PPM - about 1.3 s per day, or 54 ms per hour, if nothing refreshes it. These fields let a client judge the whole chain behind its source from one packet, without knowing the topology. ## How they accumulate down a hierarchy When a server accepts an update from its selected source, RFC 5905's system-variable update sets: - `s.rootdelay <- p.delta_r + delta` - the source's root delay plus the round-trip delay this host just measured to it; - `s.rootdisp <- p.epsilon_r + increment` - the source's root dispersion plus this hop's dispersion, jitter, PHI growth since the sample and the absolute offset, floored at a minimum value. Walk it through a data centre with two GPS-fed appliances, four internal servers and 2,000 clients: | Hop | Stratum | Measured round trip | Root delay advertised | |---|---|---|---| | GPS appliance | 1 | - | about 0 | | internal server | 2 | 0.3 ms | 0.3 ms | | client | 3 | 0.5 ms | 0.8 ms | Root dispersion grows the same way, one increment per hop, and keeps growing between updates at 15 PPM. ## From the fields to an error bound RFC 5905 defines the **root synchronization distance**: `LAMBDA = EPSILON + DELTA / 2` where `EPSILON` is root dispersion and `DELTA` root delay, and calls it "the maximum error due to all causes". For the client in the question: 1. Half the root delay: 0.8 / 2 = 0.4 ms. 2. Add the root dispersion: 0.4 + 1.2 = **1.6 ms**. Why only *half* the delay: NTP computes offset as if the outbound and return paths were equal. If they are not, the offset is wrong by at most half the round trip - the offset-and-delay arithmetic itself is a separate topic. Summed over every hop, that worst case is half the root delay. Two limits on what the bound means: - It is measured **relative to the primary reference**. If the GPS appliance itself is wrong, every downstream bound is honest about the path and still wrong about UTC; catching a wrong primary is what comparing several sources is for. - When the RFC's reference skeleton weighs a candidate source, it adds this hop's measured delay, dispersion and jitter to that source's advertised fields, so the figure a client works with for a source is a little larger than the source's own fields alone. ## Why this beats reading the stratum Compare a client that follows a public stratum 1 server across a 90 ms intercontinental path. It is **stratum 2** - shallower than our stratum 3 client - but its root delay is at least 90 ms, so its root distance is at least 45 ms before any dispersion. The stratum 3 client is bounded at 1.6 ms. Stratum counts hops; root distance bounds error. ## What happens when updates stop - NTPv4 does **not** flip a silent association to stratum 16, as NTPv3 did. Instead its dispersion keeps growing at PHI until the distance exceeds the **distance threshold MAXDIST of 1 s**, after which the source is unfit for synchronisation. - A packet advertising `rootdelay / 2 + rootdisp` of **16 s (MAXDISP)** or more fails a sanity check and is ignored. - The NTPv5 Internet-Draft (draft-ietf-ntp-ntpv5-09) refines these fields to about 4 ns resolution; until it is an RFC, NTPv4's short format applies. ## Interview takeaway State both definitions, show the hop-by-hop accumulation, compute `dispersion + delay / 2` correctly, and use it to explain why a deeper stratum can carry the tighter bound.