Some good reading there. Poll interval is in the message so that the server can "quench" clients by sending back a suggested poll interval based on server max_poll. For signedness, I believe there are many citations (I can't produce them) on packet rates and headway calculations and kiss of death codes that support the position that the poll interval is meant to be an unsigned value. It is certainly possible to run faster, as PTP often does (up to 128pkts/s), but historically setting wallclock has not required this type of precision and network path jitter and bias have degraded the solution. My opinion is that the definition should be unsigned, at least in v4. I've often proposed that you can run it faster and our commercial products certainly support rates far higher since they work the same for ntp and ptp and there is benefit in some scenarios (accurate oscillators, low round trip times, modal behaviors) where faster rates help but there are also scenarios where faster is actually worse.
For rootdelay, my opinion is that it should be signed. There is a requirement for ntp to operate that the clock be monotonically increasing as I understand it. However, if you consider 500ppm offset between clocks (client 500ppm fast) and propose a worst case processing time on the server (1 second to respond) and a best case round trip time (<100usecs per the fastest client clock), you would get a negative value. T3-T2 would be 1s. T4-T1 would be 999,600 microseconds. Rootdelay would be -400 microseconds, right? 16 bit fractional component has a resolution of 15 microseconds so it would be apparent. And now that I did the thinking, I looked as Mills' book and find the exact same conclusion 😊 The last paragraph of Section 1.5 on expected error budget specifically mentions round trip delay going negative. For root dispersion, I would have to look at the math again but I do see in the same section of the book a comment that root dispersion includes the absolute offset. That makes me think it could be negative but I am not sure. Thanks..Greg Greg Dowd Principal Engineer, FTD Microsemi 3870 N. First St. | San Jose | CA 95134 | USA Office: 408.964.7643 Email: greg.d...@microchip.com Company Website: www.microsemi.com -----Original Message----- From: questions [mailto:questions-bounces+greg.dowd=microsemi....@lists.ntp.org] On Behalf Of Jason Rabel Sent: Tuesday, October 30, 2018 8:32 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Conflicting information on packet field types EXTERNAL EMAIL EXTERNAL EMAIL 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. Jason > 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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
