[ntp:questions] Conflicting information on packet field types

Jason Rabel jasonrabel99 at gmail.com
Wed Oct 31 03:31:58 UTC 2018

I was mainly reading RFC 5905 since it's the latest, but it does make
some references back to the older RFC 4330 (SNTP). I believe it is
that document (and others) that seem to flip-flop on what is signed /
unsigned. i.e. 5905 says poll interval is signed, 4330 says poll
interval is unsigned.

I dug around in the NTP source (4.2.8p12), specifically in the
include/ntp.h file there seems to be the various structures...

In the peer struct, which the comment says, "The peer structure. Holds
state information relating to the guys we are peering with. Most of
this stuff is from section 3.2 of the spec."

u_char ppoll; /* remote poll interval */
double rootdelay; /* roundtrip delay to primary source */
double rootdisp; /* dispersion to primary source */

But further down in the pkt struct, which the comment says, "NTP packet format."

u_char ppoll; /* peer poll interval */
u_fp rootdelay; /* roundtrip delay to primary source */
u_fp rootdisp; /* dispersion to primary source*/

Poll interval is unsigned in both instances, even though the RFC says
it should (could) be signed? Again, nothing in the standard NTP
distribution would lead me to believe any negative number would ever
be sent, but with other time packages out there, who knows? TBH, I'm
not really sure what purpose sending the 'poll interval' really serves
in a client/server scenario (probably none). Maybe in a peer setup it
might hint something? I'm curious how NTP handles it, just not curious
enough to go digging through thousands of lines of code, lol.

Jumping now from Root Dispersion (which we seem to agree on is
unsigned) to Root Delay.... RFC 5905 is pretty vague on "Root Delay",
only saying it is "NTP Short Format", and like you quoted below it
*should* be unsigned.

However, RFC 4330 goes a little more in-depth saying, "This is a
32-bit signed fixed-point number indicating the total roundtrip delay
to the primary reference source, in seconds with the fraction point
between bits 15 and 16.  Note that this variable can take on both
positive and negative values, depending on the relative time and
frequency offsets.  This field is significant only in server messages,
where the values range from negative values of a few milliseconds to
positive values of several hundred milliseconds."

But to contradict even that, later in RFC 4330 there is a blurb about,
"A truly paranoid client can check that the Root Delay and Root
Dispersion fields are each greater than or equal to 0 and less than
infinity, where infinity is currently a cozy number like one second."

I found this blurb about the delay computation, "In some scenarios
where the initial frequency offset of the client is relatively large
and the actual propagation time small, it is possible for the delay
computation to become negative.  For instance, if the frequency
difference is 100 ppm and the interval T4-T1 is 64 s, the apparent
delay is -6.4 ms.  Since negative values are misleading in subsequent
computations, the value of delta should be clamped not less than
s.rho, where s.rho is the system precision described in Section 11.1,
expressed in seconds."

I know this is all a bunch of 'what if' scenarios that probably will
never happen... Especially with the packet NTP sends out apparently is
unsigned for root delay. But again my thoughts are about other time
programs out there. I'm going to take a wild guess and say that (under
normal circumstances) if NTP (or any time program) is calculating a
negative delay (and likely a huge time offset), it's probably also
considering itself unsynced and won't send out time to any clients
that request it until things normalize.


> The RFC 5905 (NTPv4) should be the authoritative source here. For the
> poll field it has:
>  8-bit signed integer representing the maximum interval between
>  successive messages, in log2 seconds.
> For the root dispersion there is:
>  The 32-bit short format is used in delay and dispersion header fields
>  where the full resolution and range of the other formats are not
>  justified.  It includes a 16-bit unsigned seconds field and a 16-bit
>  fraction field.
> So, poll is signed and root dispersion is unsigned.
> Which documents have conflicting information? I think ntpd internally
> uses an "unsigned" poll variable, but I'm not sure if it really is an
> issue as it doesn't support sub-second polling intervals.

More information about the questions mailing list