Offset and Delay Calculation

## The four numbers An NTP exchange records four moments. `T1` and `T4` come from the client's clock, `T2` and `T3` from the server's. The question gives: | Timestamp | Clock | Value | Meaning | |---|---|---|---| | `T1` | client | 1000 ms | request leaves the client | | `T2` | server | 1045 ms | request reaches the server | | `T3` | server | 1050 ms | reply leaves the server | | `T4` | client | 1055 ms | reply reaches the client | RFC 5905, the NTPv4 specification, gives the two formulas this question asks for: the **round-trip delay** `delta = (T4-T1) - (T3-T2)` and the **clock offset** `theta = ((T2-T1) + (T3-T4)) / 2`, defined as the server's time minus the client's. ## Delay, step by step 1. The whole exchange on the client's clock: `T4 - T1 = 1055 - 1000 = 55 ms`. 2. The server's hold time on the server's clock: `T3 - T2 = 1050 - 1045 = 5 ms`. 3. Time on the wire, both legs together: `55 - 5 = 50 ms`. Each subtraction compares two readings from the same clock, so the unknown offset between the clocks never enters the delay. ## Offset, step by step 1. Apparent outbound gap: `T2 - T1 = 1045 - 1000 = 45 ms`. This is the true outbound transit plus the offset. 2. Apparent return gap: `T3 - T4 = 1050 - 1055 = -5 ms`. This is the offset minus the true return transit. 3. Average them: `(45 + (-5)) / 2 = 20 ms`. Adding the two gaps makes the offset appear twice and the transit times appear with opposite signs. If the two legs were equal, the transits cancel and the sum is exactly twice the offset. Here the offset is **+20 ms**: the server's clock reads 20 ms more than the client's. A consistent story produces these numbers. Say the server really is 20 ms ahead and each leg takes 25 ms. The client sends at 1000 on its clock, which is 1020 on the server's; 25 ms later the server reads 1045. It replies at 1050; 25 ms later the server's clock would read 1075, which is 1055 on the client's. That reproduces all four timestamps and confirms both answers. ## Why the server's hold time drops out Suppose the server held the request 40 ms longer, replying at `T3 = 1090`. The reply still takes 25 ms, so it arrives at `T4 = 1095` on the client's clock. - Delay: `(1095 - 1000) - (1090 - 1045) = 95 - 45 = 50 ms`, unchanged. - Offset: `(45 + (1090 - 1095)) / 2 = (45 - 5) / 2 = 20 ms`, unchanged. The extra hold raised `T3` and `T4` by the same amount, so `T3 - T4` stayed put, and it raised `T4 - T1` and `T3 - T2` equally, so their difference stayed put. That cancellation holds only for time between the two server timestamps. If the server stamps `T3` and then spends time before the packet actually leaves, that delay is invisible to the formulas and behaves like a longer return leg. ## Sanity checks on any result - **Sign.** A negative offset means the server is behind the client. With `T2 = 1005` and `T3 = 1010` instead, the offset is `(5 + (1010 - 1055)) / 2 = -20 ms`, and the delay is still 50 ms. - **Negative delay.** RFC 5905 notes that a client whose clock frequency differs from the server's can compute a negative delay when the true delay is small. Its example: a 100 ppm difference over a 64 s interval gives -6.4 ms. The specification says to clamp the delay so it is not less than the system precision. - **Precision of the arithmetic.** RFC 5905 keeps the first-order differences at full 64-bit precision and describes converting them to floating double before the second-order sums. ## What the result does not tell you The 20 ms is exact only if each leg took half of 50 ms. Had the request taken 40 ms and the reply 10 ms, the same four timestamps would still come out exactly as given, but the true offset would differ. The arithmetic cannot detect that, which is why the delay matters: half of it, 25 ms here, bounds how wrong the offset can be. Which of many such samples a client trusts, and how it then corrects its clock, are separate subjects.