-----Original Message----- From: questions-bounces+gdowd=symmetricom....@lists.ntp.org [mailto:questions-bounces+gdowd=symmetricom....@lists.ntp.org] On Behalf Of Richard B. Gilbert Sent: Monday, December 15, 2008 1:08 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] basic questions about the leapsecond
Greg Dowd wrote: > I think it is the original rfc1305 (NTPv3) language that determined that > the bits only show up on the day of the event. While the actual > requirement is merely that they are set before 23:59 and cleared after > midnight, the supporting text is shown below. > > > "On the day prior to the insertion of a leap second the leap bits > (sys.leap) are set at the primary servers, presumably by manual means. > Subsequently, these bits show up at the local host and are passed to the > local-clock procedure. This causes the modulus of the time variable, > which is the length of the current day, to be increased or decreased by > one second as appropriate. Immediately following insertion the leap bits > are reset. Additional discussion on this issue can be found in Appendix > E." > >>From Appendix E > "The chronometry involved can be illustrated with the help of Figure 8, > which shows the details of seconds numbering just before, during and > after the last scheduled leap insertion at 23:59:59 on 31 December 1989. > Notice the NTP leap bits are set on the day prior to insertion, as > indicated by the <169>+<170> symbols on the figure. Since this makes the > day one second longer than usual, the NTP day rollover will not occur > until the end of the first occurrence of second 800. The UTC time > conversion routines must notice the apparent time and the leap bits and > handle the timescale conversions accordingly. Immediately after the leap > insertion both timescales resume ticking the seconds as if the leap had > never happened. The chronometric correspondence between the UTC and NTP > timescales continues, but NTP has forgotten about all past leap > insertions. In NTP chronometric determination of UTC time intervals > spanning leap seconds will thus be in error, unless the exact times of > insertion are known." > > When ntpv4 is standardized, the language changes to "leap at the end of > the current month". > > > -----Original Message----- > From: questions-bounces+gdowd=symmetricom....@lists.ntp.org > [mailto:questions-bounces+gdowd=symmetricom....@lists.ntp.org] On Behalf > Of David J Taylor > Sent: Monday, December 15, 2008 9:39 AM > To: questions@lists.ntp.org > Subject: Re: basic questions about the leapsecond > > David L. Mills wrote: >> Guys, >> >> See http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap for what >> actually is in the implementation. As visivle here, the Spectracom >> (GPS/WWVB) driver, ACTS telephone modem driver and WWV audio driver do >> correctly display leap information. The Meinberg GPS receiver, EndRun >> CDMA receiver and audio IRIG driver do not display leapsecond >> information. > [] >> Dave > > Dave, > > Thanks for that summary. My own GPS system using the Garmin GPS18 LVC > and > the official ntp code for FreeBSD also does /not/ show the leap second. > > Is this something fundamental to all GPS - in that they don't indicate > until nearer the end of the month? > > Thanks, > David Did you READ the message you replied to? It seems quite clear to me! _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions Did I miss something? The question I replied to asked if any generalizations could be drawn about the behavior of various GPS devices, did it not? Dave Mill's reply described exactly the behavior of the current distribution from ntpd land and a sampling of reflock driver operations. It made no attempt to explain why some devices behave one way and some another. For instance, I think it was Martin that noted that IRIG doesn't provide leap second info unless the 1344 ToM enhancements are added. It might be useful to understand that 1344 only allows the leap bit to be set in the last 10 minutes of the day. Then you would understand that no audio IRIG driver will ever set leap well on its own. As for GPS, the leap second warning is typically provided a few months early. So, why do so many drivers not report it immediately? The fundamental cause is likely that most of these drivers, including ones I've worked on, were written in the window from 1992 - today. In that window, the ietf rfc defining NTP behavior restricts the driver to setting the bit until the day of the event per my posting. Meanwhile, time has marched on and v4 has been available for a long time but it is not standardized and so there is no clear definition of whether what the refclock drivers do is correct or incorrect. >From my point of view, I find understanding the history and context of the unexplained creates a frame of reference. Then I don't ask so many stupid questions. At least hopefully I don't ask the same question twice. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
