Why does an NTP client not simply set its clock to the transmit time carried in the server's reply?

## The problem with one timestamp A client that wants the correct time has to ask a server for it, and the answer travels over a network. The server stamps its reply with the time it was sent, but the client reads that stamp only after the reply has crossed the path back. If the client copied the stamp into its own clock, it would be set to a moment that is already in the past by the **return transit time**. That transit time is not a constant. It depends on distance, on queues in every router along the way and on how busy the two hosts are. On a local network it may be well under a millisecond; across a continent it can be tens of milliseconds. A single timestamp gives the client no way to know how stale the answer is, so it cannot correct for it. ## The four timestamps of one exchange The Network Time Protocol, version 4 (RFC 5905, which obsoletes RFC 1305 and the separate SNTP document RFC 4330), solves this by recording four moments for every request and reply. RFC 5905 names the packet fields **origin**, **receive** and **transmit**; the fourth, the **destination timestamp**, is never sent, because the client records it when the reply arrives. | Timestamp | Recorded by | Moment | Where it travels | |---|---|---|---| | `T1` origin | client clock | request leaves the client | copied back by the server in the reply's Origin Timestamp | | `T2` receive | server clock | request reaches the server | reply's Receive Timestamp | | `T3` transmit | server clock | reply leaves the server | reply's Transmit Timestamp | | `T4` destination | client clock | reply reaches the client | kept locally, not a header field | The client also uses `T1` as a check: a reply whose origin timestamp does not match the transmit time the client last sent is, in RFC 5905's word, **bogus**, and is discarded. That is how the client knows the reply answers its own request. ## Why taking differences on one clock works The client's and the server's clocks disagree by an unknown amount, the **clock offset**. Comparing a client reading with a server reading directly would mix that offset into every result. NTP avoids this by only subtracting readings taken on the same clock: 1. `T4 - T1` is the whole exchange as the client saw it, measured entirely on the client's clock. 2. `T3 - T2` is how long the server held the request, measured entirely on the server's clock. 3. Subtracting the second from the first leaves the time spent on the wire in both directions: the **round-trip delay**, `delta = (T4-T1) - (T3-T2)`. 4. The **offset**, `theta = ((T2-T1) + (T3-T4)) / 2`, averages the apparent gap on the way out with the apparent gap on the way back. RFC 5905 defines it as the server's time minus the client's, so a positive value means the server is ahead. The offset formula only works because of one assumption: the request and the reply took the **same time** on the wire. Under that assumption each leg took half the round-trip delay, and the client can place the server's reading on its own timeline. ## A small illustration Suppose the server is exactly on time and each leg takes 30 ms. The server stamps its reply `T3`, and the reply arrives 30 ms later. A client that copied `T3` would end up 30 ms slow on every update. A client that uses all four timestamps sees a 60 ms round trip, attributes 30 ms to the return leg, and lands on the correct time. ## What this method still cannot see - **Asymmetric paths.** If the request took longer than the reply, or the reverse, the offset is wrong by half the difference between the legs, and nothing in the four timestamps shows it. The error is bounded by half the round-trip delay. - **One sample is noisy.** Queues vary from packet to packet, so a client keeps several exchanges per server and chooses among them; filtering samples and choosing among servers is a separate subject. - **Applying the result is separate.** The offset says how far the clock is off; how the client then adjusts its clock, gradually or in one step, is the clock-discipline subject. The point that survives every interview follow-up is this: the four timestamps exist because a single timestamp cannot tell the client how old it is, and the arithmetic that replaces it is exact for the round trip but only an estimate, under a symmetry assumption, for the offset.