Re: [ntp:questions] Conflicting information on packet field types
On Tue, Oct 30, 2018 at 10:31:58PM -0500, Jason Rabel wrote: > 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. Interesting. RFC 1305 has signed root delay and dispersion too. I never noticed that. I thought the only differences in the format of NTPv3 and NTPv4 packets was the IPv6 reference ID and extension fields. > 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 two NTP implementations I'm most familiar with both work with an absolute value of the delay. So, even if the frequency error is so large that the measured delay is negative, the root delay should accumulate a positive value. A potential issue is with values in the 32768-65536 range, which could be used by a server that lost synchronization long time ago and old clients following RFC 1305/4330 would misinterpret it as a negative value. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd behavior to replace ntpdate single shot
All, On Wed, Oct 24, 2018 at 8:49 AM Matthew Weber wrote: > > I'm working on an update to an init script for Buildroot and was > wondering if I can accomplish the following sequence with a single > call to ntpd. > I ended up going the route of using sntp in-place of ntpdate and kept ntpd as it originally was. https://patchwork.ozlabs.org/patch/992167/ > Original sequence > - > ntpdate#blocks > ntpd -g > #time is valid > > Updated scenario #1 - Time is never initially set and I always > timeout. I believe it's a step issue and I tried including the -x and > -G. > - > ntpd -g -x -G -w 15 # blocks from 15sec, times out and continues > # time is not valid but server lists in ntpq -p > > Updated scenario #2 - Works by forcing the step information to drop > and time gets initially set and then maintained. > - > ntpd -gq & > # manage the pid from the one-shot with a while loop until the timeout > and kill ntpd as it would hang forever if the server can't be reached > (is there away around this?) > ntpd -g > # time is valid -- Matthew L Weber / Pr Software Engineer Airborne Information Systems / RC Linux Secure Platforms MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA www.rockwellcollins.com Note: Any Export License Required Information and License Restricted Third Party Intellectual Property (TPIP) content must be encrypted and sent to matthew.we...@corp.rockwellcollins.com. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Conflicting information on packet field types
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 pa
Re: [ntp:questions] Conflicting information on packet field types
That should have read section 11.5 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 greg.d...@microchip.com Sent: Thursday, November 1, 2018 9:06 AM To: jasonrabe...@gmail.com; questions@lists.ntp.org Subject: Re: [ntp:questions] Conflicting information on packet field types 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 f
