Re: basic questions about the leapsecond

GDowd@xxxxxxxxxxxxxxx (Greg Dowd) writes:

-----Original Message-----
From: questions-bounces+gdowd=symmetricom.com@xxxxxxxxxxxxx
[mailto:questions-bounces+gdowd=symmetricom.com@xxxxxxxxxxxxx] On Behalf
Of Richard B. Gilbert
Sent: Monday, December 15, 2008 1:08 PM
To: questions@xxxxxxxxxxxxx
Subject: Re: 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.com@xxxxxxxxxxxxx
[mailto:questions-bounces+gdowd=symmetricom.com@xxxxxxxxxxxxx] On
Behalf
Of David J Taylor
Sent: Monday, December 15, 2008 9:39 AM
To: questions@xxxxxxxxxxxxx
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!

He asked if the Garmin GPS18LVC reported leap second information before the
fact. David never talked about that receiver.

Reading the documentation on the GPS18 it seems it does NOT transmit the
information that a leap second will occur. It does correct its time
transmission to include the leap second, including broadcasting how many
leap seconds have been inserted in the past. But that would seem to be
after the fact, not before the fact.
Ie, it would seem that if you are getting your time from the Garmin GPS, at
midnight on Dec 31, ntp will suddenly find that it is out by one second.
Since that is longer than 128ms, it will jump the time by resetting the
system clock by a second the next time it queries the GPS receiver input ( somewhere
between 16 and 1000 seconds later, depending on the poll interval for the
GPS receiver.)

Ie, for a while your system time will be out by a second.



_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxx
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.
.

Relevant Pages

  • Re: basic questions about the leapsecond
    ... basic questions about the leapsecond ... "On the day prior to the insertion of a leap second the leap bits ... driver, ACTS telephone modem driver and WWV audio driver ...
    (comp.protocols.time.ntp)
  • Re: basic questions about the leapsecond
    ... basic questions about the leapsecond ... "On the day prior to the insertion of a leap second the leap bits ... driver, ACTS telephone modem driver and WWV audio driver ...
    (comp.protocols.time.ntp)
  • Re: basic questions about the leapsecond
    ... There is absolutely nothing the driver can do if the information is ... the GPS unit. ... values on those sources during a leap-second update, using just the PPS ... And my system is showing the leap second warning. ...
    (comp.protocols.time.ntp)
  • Re: basic questions about the leapsecond
    ... i.e. NTP 4.2.4p5 and earlier. ... driver, ACTS telephone modem driver and WWV audio driver do ... Of course the Meinberg GPS receiver is aware of the upcoming leap ... interval before the time the leap second is actually inserted. ...
    (comp.protocols.time.ntp)
  • Re: basic questions about the leapsecond
    ... i.e. NTP 4.2.4p5 and earlier. ... driver, ACTS telephone modem driver and WWV audio driver do ... Of course the Meinberg GPS receiver is aware of the upcoming leap ... interval before the time the leap second is actually inserted. ...
    (comp.protocols.time.ntp)