6

It's about the Network Time Protocol, specified in RFC 5905.

I understand that the Root Delay field of NTPv4 packets (or the Synchronizing Distance field, as it is named in the previous version NTPv3) is a number indicating the estimated roundtrip delay to the primary/reference clock.

But, why does the protocol need to know the delay to the primary clock? As described in the specification, it properly uses the Origin, Receive and Transmit timestamp fields to calculate the correct time (in cooperation with the server/peer), and doesn't even make any direct or indirect communication with the primary clock in the time calculation "trip".

Is it because the server/peer has been synchronized by the reference clock in the past, and now wants to inform the client about the delay that has taken place?

By the way, what is the meaning of the related Root Dispersion field? Unfortunately, I didn't understand the dispersion concept, which isn't really explained in detail.

Community
  • 1
  • 1
Reflection
  • 1,936
  • 3
  • 21
  • 39

1 Answers1

2

ntpd not only sets the local clock but can also act as a timeserver for other ntp clients. To do this it needs to know its accuracy. To calculate this it looks at the min and max round-trip delay from the (presumably perfect) root clock as well as its own error in its system clock. It can then advertise how good its clock is to clients.

Root delay DELTA is the range of delays (max - min) from the root clock. The error contributed by this part is assumed to be DELTA / 2.

Dispersion is the error in the local system clock since it was last synchronized with the upstream clock. So this will look like a sawtooth function that drops to 0 when synced, then grows linearly until the next sync.

stark
  • 12,615
  • 3
  • 33
  • 50
  • What value does the Root Delay field hold in client mode (when ntpd doesn't act as a time server)? Is it implementation-dependant? However, what about cases in which ntpd acts as a server, but not directly synchronized to a reference clock? (That's to say, stratum is higher than 1) – Reflection Apr 23 '14 at 22:36
  • I haven't looked at the code, but based on the RFC it looks like the sum of its delay plus the upstream server root delay. So root delay accumulates across strata. – stark Apr 24 '14 at 00:44
  • Thanks a lot! I guess your answer address my question about the secondary server (with higher stratum). But, what about the question about client-mode packets? What this field should contain for a not yet been synchronized client sends a request to a time-server? zeros? – Reflection Apr 26 '14 at 08:57
  • I would think that to avoid lying you start root delay and stratum at max values, then reduce as you find servers and peers. Its better to look at some working code, though. – stark Apr 26 '14 at 17:00
  • But even if I could communicate with servers/peers that way, it does not mean that it meets the standard (and my question is about the standard). – Reflection Apr 26 '14 at 17:11
  • The standard talks about combining multiple sources and eliminating outliers, so I think starting off as an outlier meets the spec given no valid data. – stark Apr 26 '14 at 19:08