Hi...

I'm a bit worried regarding the leapsecond, since I'm not finding much
documentation about it... I have a simple (but unanswered) doubt: Do I
have to manually configure something?

Could you point some docs?

We have the following structure repeated 3 times:

+------- --+ 1 PPS +--------+  IRIG  +-------+   +-----------+
|Atomic Ref|------>|IRIG Gen|------->|NTP st1|-->|pub NTP st2|
+----------+ 10Mhz +--------+ + 1PPS +-------+   +-----------+
                                        ^            ^	
                                        |            |

                                     other st1    other st2

- 1 st1 server is freebsd + ntpd + IRIG audio
- 1 st1 server is symmetricom syncserver S250
- 1 st1 server is spectracom netclock 9283

At the IRIG generator we have to manually set the leapsecond bit.

Could anyone tell me if these servers could read the leap bit correctly
from IRIG signal? Specially IRIG audio?

How could I test it at NTP? (Since I have made the adjust at IRIG gen
how could I tell if ntp can read it correctly?)

We have also 2 systems with GPS:

+---+  NMEA  +-------+
|GPS|------->|NTP st1|
+---+ + 1PPS +-------+

One of them is a Trimble Acutime 2000, and the other is a Garmin 18LVC.
Do I have to worry about these ntp servers?

Thank you.
Antonio M. Moreiras

Hi Antonio,

Antonio M. Moreiras wrote:
> Hi...
> 
> I'm a bit worried regarding the leapsecond, since I'm not finding much
> documentation about it... I have a simple (but unanswered) doubt: Do I
> have to manually configure something?
> 
> Could you point some docs?

Here's some basic information:
http://www.meinberg.de/english/info/ntp.htm

> We have the following structure repeated 3 times:
> 
> +------- --+ 1 PPS +--------+  IRIG  +-------+   +-----------+
> |Atomic Ref|------>|IRIG Gen|------->|NTP st1|-->|pub NTP st2|
> +----------+ 10Mhz +--------+ + 1PPS +-------+   +-----------+
>                                         ^            ^
>                                         |            |
> 
>                                      other st1    other st2
> 
> - 1 st1 server is freebsd + ntpd + IRIG audio
> - 1 st1 server is symmetricom syncserver S250
> - 1 st1 server is spectracom netclock 9283
> 
> At the IRIG generator we have to manually set the leapsecond bit.
> 
> Could anyone tell me if these servers could read the leap bit correctly
> from IRIG signal? Specially IRIG audio?
> 
> How could I test it at NTP? (Since I have made the adjust at IRIG gen
> how could I tell if ntp can read it correctly?)
> 
> We have also 2 systems with GPS:
> 
> +---+  NMEA  +-------+
> |GPS|------->|NTP st1|
> +---+ + 1PPS +-------+
> 
> One of them is a Trimble Acutime 2000, and the other is a Garmin 18LVC.
> Do I have to worry about these ntp servers?

Please note your NTP servers need to receive a leap second announcement e.g.
one day *before* the leap second actually occurs, otherwise they can not
handle the leap second correctly.

Leap second announcements can be received from an upstream NTP server, from
a reference time source, (IRIG, GPS, ..), or from a leap second file. It is
important to check whether *both* the reference time transport format (IRIG
frame type or NMEA format) and also NTPs reference clock driver configured
for that refclock support leap second announcements.

Most commonly used IRIG frame formats have not specified a leap second
announcement flag, but some formats like IEEE1344 support this. So it
depends on the IRIG format you are using if a leap second announcement
arrives at your IRIG receiver.

I'm also not sure whether NMEA supports leap second announcements. E.g. the
parse driver (type 8) does. For an NTP server it is *not* sufficient if
only the leap second is transmitted as second 60 in a time string).

If your NTP servers run NTP v4 then the best way is to install the NIST leap
second file. See:
http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.13.

Don't forget to enable autokey on your servers since otherwise the leap
second file will not be evaluated.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

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.  The USNO and NIST servers do not show leap bits in the VME 
or ACTS associations, but that might not be significant until the day 
before the leap. Our servers pogo.udel.edu and rackety.udel.edu are 
correctly configure and the leap warning bits in the driver associations 
correctly set. To check a server near you, run ntpq, as and rv commands 
for the system peer and verify the leap bits are set to 01,

As mentioned in the documentation, it is not necessary to run Autokey to 
download the leapseconds file from NIST. It is availabe via FTP from the 
pub directory and leap-seconds file.

Dave

Martin Burnicki wrote:

>Hi Antonio,
>
>Antonio M. Moreiras wrote:
>  
>
>>Hi...
>>
>>I'm a bit worried regarding the leapsecond, since I'm not finding much
>>documentation about it... I have a simple (but unanswered) doubt: Do I
>>have to manually configure something?
>>
>>Could you point some docs?
>>    
>>
>
>Here's some basic information:
>http://www.meinberg.de/english/info/ntp.htm
>
>  
>
>>We have the following structure repeated 3 times:
>>
>>+------- --+ 1 PPS +--------+  IRIG  +-------+   +-----------+
>>|Atomic Ref|------>|IRIG Gen|------->|NTP st1|-->|pub NTP st2|
>>+----------+ 10Mhz +--------+ + 1PPS +-------+   +-----------+
>>                                        ^            ^
>>                                        |            |
>>
>>                                     other st1    other st2
>>
>>- 1 st1 server is freebsd + ntpd + IRIG audio
>>- 1 st1 server is symmetricom syncserver S250
>>- 1 st1 server is spectracom netclock 9283
>>
>>At the IRIG generator we have to manually set the leapsecond bit.
>>
>>Could anyone tell me if these servers could read the leap bit correctly
>>from IRIG signal? Specially IRIG audio?
>>
>>How could I test it at NTP? (Since I have made the adjust at IRIG gen
>>how could I tell if ntp can read it correctly?)
>>
>>We have also 2 systems with GPS:
>>
>>+---+  NMEA  +-------+
>>|GPS|------->|NTP st1|
>>+---+ + 1PPS +-------+
>>
>>One of them is a Trimble Acutime 2000, and the other is a Garmin 18LVC.
>>Do I have to worry about these ntp servers?
>>    
>>
>
>Please note your NTP servers need to receive a leap second announcement e.g.
>one day *before* the leap second actually occurs, otherwise they can not
>handle the leap second correctly.
>
>Leap second announcements can be received from an upstream NTP server, from
>a reference time source, (IRIG, GPS, ..), or from a leap second file. It is
>important to check whether *both* the reference time transport format (IRIG
>frame type or NMEA format) and also NTPs reference clock driver configured
>for that refclock support leap second announcements.
>
>Most commonly used IRIG frame formats have not specified a leap second
>announcement flag, but some formats like IEEE1344 support this. So it
>depends on the IRIG format you are using if a leap second announcement
>arrives at your IRIG receiver.
>
>I'm also not sure whether NMEA supports leap second announcements. E.g. the
>parse driver (type 8) does. For an NTP server it is *not* sufficient if
>only the leap second is transmitted as second 60 in a time string).
>
>If your NTP servers run NTP v4 then the best way is to install the NIST leap
>second file. See:
>http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.13.
>
>Don't forget to enable autokey on your servers since otherwise the leap
>second file will not be evaluated.
>
>
>Martin
>  
>

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 

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@lists.ntp.org
[mailto:questions-bounces+gdowd=symmetricom.com@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 

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@lists.ntp.org
> [mailto:questions-bounces+gdowd=symmetricom.com@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!

David,

In the NTPv3 spec the leap bits are to be set on the day of the leap. 
This is compliant with the new NTPv4 spec; that spec is more liberal in 
order to support and prioritize leap warnings when multiple means are 
available. In cases where the radio delivers a timecode via serial port, 
some radios include provisions for leap warning; some do not. I don't 
know if an NMEA sentence has provisions for that. There are no 
provisions for leap warning in IRIG devices I have.

I  don't know if the Meinberg GPS or EndRun CDMA receiver include 
provisions for leap warning. If so, it should appear in the NTP header 
on the day of the leap. Both receivers use an embedded Linux system 
which in principle has the same provisions as the public distribution..

Dave

David J Taylor wrote:

> 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
>
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions

So, if I understand, I have to:

1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400
2 - rename the file to ntp.leapseconds and put it in /etc
3 - stop and start ntpd
4 - verify the warning bits

It should be done at primary servers and the others would get
automatically the file if using autokey.

It could be done also at any stratum if one don't trust the references
regarding this issue.

Don't having the file, and if not using autokey and references with the
information, the client will relay at information from the majority of
survivor references. If they warn the leapsecond, the client will get it
correctly.

Is this correct?

Thanks.
Antonio M. Moreiras.

David L. Mills escreveu:
> Guys,
> 
> See http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap for what 
> actually is in the implementation. (...)
> As mentioned in the documentation, it is not necessary to run Autokey to 
> download the leapseconds file from NIST. It is availabe via FTP from the 
> pub directory and leap-seconds file.
> 
> Dave
> 

-----Original Message-----
From: questions-bounces+gdowd=symmetricom.com@lists.ntp.org
[mailto:questions-bounces+gdowd=symmetricom.com@lists.ntp.org] On Behalf
Of Richard B. Gilbert
Sent: Monday, December 15, 2008 1:08 PM
To: questions@lists.ntp.org
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@lists.ntp.org
> [mailto:questions-bounces+gdowd=symmetricom.com@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.  

Greg Dowd wrote:
> -----Original Message-----
> From: questions-bounces+gdowd=symmetricom.com@lists.ntp.org
> [mailto:questions-bounces+gdowd=symmetricom.com@lists.ntp.org] On Behalf
> Of Richard B. Gilbert
> Sent: Monday, December 15, 2008 1:08 PM
> To: questions@lists.ntp.org
> 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@lists.ntp.org
>> [mailto:questions-bounces+gdowd=symmetricom.com@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.  

I don't recall just when the last leap second was.  The last one I 
remember was maybe three or four years ago.  It looked as if the entire 
world was confused by it and it took several hours for things to settle 
down.

Perhaps part of the problem was people adding the leap second at "local 
midnight" rather than at 0000 UTC.

We'll get through it somehow or other!

GDowd@symmetricom.com (Greg Dowd) writes:

>-----Original Message-----
>From: questions-bounces+gdowd=symmetricom.com@lists.ntp.org
>[mailto:questions-bounces+gdowd=symmetricom.com@lists.ntp.org] On Behalf
>Of Richard B. Gilbert
>Sent: Monday, December 15, 2008 1:08 PM
>To: questions@lists.ntp.org
>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@lists.ntp.org
>> [mailto:questions-bounces+gdowd=symmetricom.com@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!

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@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.  

Once upon a time, Unruh  <unruh-spam@physics.ubc.ca> said:
>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. 

If you have both a NMEA GPS unit (AFAIK there's no NMEA sentence to
alert for pending leap seconds, and even if there is, there doesn't
appear to be support for such in ntpd) and NTP servers specified (that
do set the leap second flag in advance), will ntpd learn about the leap
second from the other servers and use it (even though the GPS/PPS unit
is the "system peer")?

-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

David L. Mills wrote:
> David,
>
> In the NTPv3 spec the leap bits are to be set on the day of the leap.
> This is compliant with the new NTPv4 spec; that spec is more liberal
> in order to support and prioritize leap warnings when multiple means
> are available. In cases where the radio delivers a timecode via
> serial port, some radios include provisions for leap warning; some do
> not. I don't know if an NMEA sentence has provisions for that. There
> are no provisions for leap warning in IRIG devices I have.
>
> I  don't know if the Meinberg GPS or EndRun CDMA receiver include
> provisions for leap warning. If so, it should appear in the NTP header
> on the day of the leap. Both receivers use an embedded Linux system
> which in principle has the same provisions as the public
> distribution..
>
> Dave

Thanks, Dave.  I don't know about the NMEA sentence either, but I don't 
recall seeing that possibility.  On my GPS-based server, it does also have 
Internet sources, but even though one of those sources is showing the leap 
bit, my server is not.  I'll have to check on December 31st.  It will be 
disappinting if I have similar problems to last time!

  http://www.satsignal.eu/ntp/ntp-events.htm#leapsecond

In view of the popularity of the GPS18-LVC it's a pity that the driver 
support for the leap second isn't better, but I appreciate that being able 
to test once every few years doesn't make things any easier!

Here are the results from my own server, and two of the five Internet 
servers to which it is connected.  Disappointingly, the three pool servers 
didn't respond to the "ntpq -c rv" command.  Of the other two, one 
indicates a leap second, and the other doesn't.

__________________________________________________________
C:\>ntpq -c rv pixie
assID=0 status=2484 leap_none, sync_uhf_clock/PPS, 8 events, 
event_peer/strat_ch
g,
version="ntpd 4.2.0-a Sun May  8 06:01:21 UTC 2005 (1)",
processor="i386", system="FreeBSD/5.4-RELEASE", leap=00, stratum=1,
precision=-17, rootdelay=0.000, rootdispersion=2.125, peer=5113,
refid=PPS, reftime=ccf1ca39.2c218fe1  Tue, Dec 16 2008  6:33:29.172,
poll=6, clock=ccf1ca43.fbb22262  Tue, Dec 16 2008  6:33:39.983, state=4,
offset=0.008, frequency=41.314, jitter=0.005, stability=0.018

C:\>ntpq -n -p pixie
     remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
+78.129.142.80   195.66.241.3     2 u   46   64  377   22.441    2.319 
0.441
+212.13.194.96   212.13.204.4     3 u   28   64  377   20.532    1.125 
1.354
+213.130.44.252  128.250.33.242   2 u   37   64  377   22.043    1.964 
0.322
-88.96.233.89    192.53.103.108   2 u   54   64  377   64.083    3.175 
0.593
-130.88.200.6    193.62.22.98     2 u    3   64  377   26.839   10.450 
0.467
*127.127.20.1    .PPS.            0 l   14   64  377    0.000    0.008 
0.008

C:\>ntpq -c rv 78.129.142.80
78.129.142.80: timed out, nothing received
***Request timed out

C:\>ntpq -c rv 212.13.194.96
212.13.194.96: timed out, nothing received
***Request timed out

C:\>ntpq -c rv 213.130.44.252
213.130.44.252: timed out, nothing received
***Request timed out

C:\>ntpq -c rv 88.96.233.89
assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.2.4p4@1.1520-o Tue Nov  4 15:54:13 UTC 2008 (1)",
processor="i386", system="FreeBSD/7.1-PRERELEASE", leap=00, stratum=2,
precision=-21, rootdelay=83.613, rootdispersion=24.271, peer=30612,
refid=192.53.103.108,
reftime=ccf1c8ec.39dc931f  Tue, Dec 16 2008  6:27:56.226, poll=10,
clock=ccf1cac8.5e837314  Tue, Dec 16 2008  6:35:52.369, state=4,
offset=0.174, frequency=-66.147, jitter=0.438, noise=0.392,
stability=0.020, tai=0,
access_policy="experimental server not suitable for production use"

C:\>ntpq -c rv 130.88.200.6
assID=0 status=46f4 leap_add_sec, sync_ntp, 15 events, 
event_peer/strat_chg,
version="ntpd 4.2.0-a Wed Jul 23 12:48:29 BST 2008 (1)",
processor="i386", system="FreeBSD/6.3-STABLE", leap=01, stratum=2,
precision=-17, rootdelay=1.723, rootdispersion=54.425, peer=38190,
refid=193.62.22.98,
reftime=ccf1ca10.7782ce5d  Tue, Dec 16 2008  6:32:48.466, poll=10,
clock=ccf1cade.07d6bcb6  Tue, Dec 16 2008  6:36:14.030, state=4,
offset=-10.270, frequency=-0.505, jitter=9.321, stability=0.004
__________________________________________________________ 

cmadams@hiwaay.net (Chris Adams) writes:

>Once upon a time, Unruh  <unruh-spam@physics.ubc.ca> said:
>>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. 

>If you have both a NMEA GPS unit (AFAIK there's no NMEA sentence to
>alert for pending leap seconds, and even if there is, there doesn't
>appear to be support for such in ntpd) and NTP servers specified (that
>do set the leap second flag in advance), will ntpd learn about the leap
>second from the other servers and use it (even though the GPS/PPS unit
>is the "system peer")?

From reading the ntp docs, it seems that if you download the leapseconds
file, call it /etc/ntp.leapseconds  and restart ntpd, then ntpd will read that
 file, and set the leapsecond flag on your system in the last month or day. 

I have not tested this ( my only machine running ntpd has the leapseconds
flag already set-- probably from the other two servers other than the GPS
shm refclock server which does not set the leap flag.).

"David J Taylor" <david-taylor@blueyonder.neither-this-part.nor-this-bit.co.uk> writes:

>David L. Mills wrote:
>> David,
>>
>> In the NTPv3 spec the leap bits are to be set on the day of the leap.
>> This is compliant with the new NTPv4 spec; that spec is more liberal
>> in order to support and prioritize leap warnings when multiple means
>> are available. In cases where the radio delivers a timecode via
>> serial port, some radios include provisions for leap warning; some do
>> not. I don't know if an NMEA sentence has provisions for that. There
>> are no provisions for leap warning in IRIG devices I have.
>>
>> I  don't know if the Meinberg GPS or EndRun CDMA receiver include
>> provisions for leap warning. If so, it should appear in the NTP header
>> on the day of the leap. Both receivers use an embedded Linux system
>> which in principle has the same provisions as the public
>> distribution..
>>
>> Dave

>Thanks, Dave.  I don't know about the NMEA sentence either, but I don't 
>recall seeing that possibility.  On my GPS-based server, it does also have 
>Internet sources, but even though one of those sources is showing the leap 
>bit, my server is not.  I'll have to check on December 31st.  It will be 
>disappinting if I have similar problems to last time!

>  http://www.satsignal.eu/ntp/ntp-events.htm#leapsecond

>In view of the popularity of the GPS18-LVC it's a pity that the driver 
>support for the leap second isn't better, but I appreciate that being able 
>to test once every few years doesn't make things any easier!

As far as I can see, the GPS18-LVC unit does NOT warn of leapseconds. There is
absolutely nothing the driver can do if the information is not supplied by
the GPS unit.

>Here are the results from my own server, and two of the five Internet 
>servers to which it is connected.  Disappointingly, the three pool servers 
>didn't respond to the "ntpq -c rv" command.  Of the other two, one 
>indicates a leap second, and the other doesn't.

>__________________________________________________________
>C:\>ntpq -c rv pixie
>assID=0 status=2484 leap_none, sync_uhf_clock/PPS, 8 events, 
>event_peer/strat_ch
>g,
>version="ntpd 4.2.0-a Sun May  8 06:01:21 UTC 2005 (1)",
>processor="i386", system="FreeBSD/5.4-RELEASE", leap=00, stratum=1,
>precision=-17, rootdelay=0.000, rootdispersion=2.125, peer=5113,
>refid=PPS, reftime=ccf1ca39.2c218fe1  Tue, Dec 16 2008  6:33:29.172,
>poll=6, clock=ccf1ca43.fbb22262  Tue, Dec 16 2008  6:33:39.983, state=4,
>offset=0.008, frequency=41.314, jitter=0.005, stability=0.018

>C:\>ntpq -n -p pixie
>     remote           refid      st t when poll reach   delay   offset 
>jitter
>==============================================================================
>+78.129.142.80   195.66.241.3     2 u   46   64  377   22.441    2.319 
>0.441
>+212.13.194.96   212.13.204.4     3 u   28   64  377   20.532    1.125 
>1.354
>+213.130.44.252  128.250.33.242   2 u   37   64  377   22.043    1.964 
>0.322
>-88.96.233.89    192.53.103.108   2 u   54   64  377   64.083    3.175 
>0.593
>-130.88.200.6    193.62.22.98     2 u    3   64  377   26.839   10.450 
>0.467
>*127.127.20.1    .PPS.            0 l   14   64  377    0.000    0.008 
>0.008

>C:\>ntpq -c rv 78.129.142.80
>78.129.142.80: timed out, nothing received
>***Request timed out

>C:\>ntpq -c rv 212.13.194.96
>212.13.194.96: timed out, nothing received
>***Request timed out

>C:\>ntpq -c rv 213.130.44.252
>213.130.44.252: timed out, nothing received
>***Request timed out

>C:\>ntpq -c rv 88.96.233.89
>assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
>version="ntpd 4.2.4p4@1.1520-o Tue Nov  4 15:54:13 UTC 2008 (1)",
>processor="i386", system="FreeBSD/7.1-PRERELEASE", leap=00, stratum=2,
>precision=-21, rootdelay=83.613, rootdispersion=24.271, peer=30612,
>refid=192.53.103.108,
>reftime=ccf1c8ec.39dc931f  Tue, Dec 16 2008  6:27:56.226, poll=10,
>clock=ccf1cac8.5e837314  Tue, Dec 16 2008  6:35:52.369, state=4,
>offset=0.174, frequency=-66.147, jitter=0.438, noise=0.392,
>stability=0.020, tai=0,
>access_policy="experimental server not suitable for production use"

>C:\>ntpq -c rv 130.88.200.6
>assID=0 status=46f4 leap_add_sec, sync_ntp, 15 events, 
>event_peer/strat_chg,
>version="ntpd 4.2.0-a Wed Jul 23 12:48:29 BST 2008 (1)",
>processor="i386", system="FreeBSD/6.3-STABLE", leap=01, stratum=2,
>precision=-17, rootdelay=1.723, rootdispersion=54.425, peer=38190,
>refid=193.62.22.98,
>reftime=ccf1ca10.7782ce5d  Tue, Dec 16 2008  6:32:48.466, poll=10,
>clock=ccf1cade.07d6bcb6  Tue, Dec 16 2008  6:36:14.030, state=4,
>offset=-10.270, frequency=-0.505, jitter=9.321, stability=0.004
>__________________________________________________________ 

Unruh wrote:
> "David J Taylor"
[]
>> In view of the popularity of the GPS18-LVC it's a pity that the
>> driver support for the leap second isn't better, but I appreciate
>> that being able to test once every few years doesn't make things any
>> easier!
>
> As far as I can see, the GPS18-LVC unit does NOT warn of leapseconds.
> There is absolutely nothing the driver can do if the information is
> not supplied by
> the GPS unit.

Yes, that was poorly worded - I meant "shouldn't NTP note the leap-second 
flags from the other Internet upstream servers, and base its whole second 
values on those sources during a leap-second update, using just the PPS 
part of the GPS signal?"  The would appear to apply to any GPS source 
which is PPS + NMEA....

David 

Unruh wrote:
[]
> From reading the ntp docs, it seems that if you download the
> leapseconds file, call it /etc/ntp.leapseconds  and restart ntpd,
> then ntpd will read that file, and set the leapsecond flag on your
> system in the last month or day.
[]

This seems a lot simpler than the method described in the docs:

  http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.13.

which talk about "crypto directory" and "autokey", and seem (to me) a lot 
more complicated than just copying a renamed file and restarting ntpd!

There is also the remark: "If the top level NTP server is unable to obtain 
the leap second file automatically...".  Does this mean that NTP will try 
and fetch this file by itself?

Some clarification would be appreciated.

David 

Dave,

David L. Mills wrote:
> Guys,
> 
> See http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap for what
> actually is in the implementation. 

.... which is valid for the current developer version, NTP 4.2.5p[something],
but must not necessarily match the current (or earlier) stable versions,
i.e. NTP 4.2.4p5 and earlier.

> 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.  

.... yet. Of course the Meinberg GPS receiver is aware of the upcoming leap
second, and it will set the leap second announcement flag a certain
interval before the time the leap second is actually inserted.

The interval depends on the firmware version. It is 59 minutes in older
firmware versions (due to compatibility with the German longwave
transmitter DCF77) and has been extended in recent versions to 1 day if the
Uni Erlangen string format is used.

> The USNO and NIST servers do not show leap bits in the VME 
> or ACTS associations, but that might not be significant until the day
> before the leap. Our servers pogo.udel.edu and rackety.udel.edu are
> correctly configure and the leap warning bits in the driver associations
> correctly set. To check a server near you, run ntpq, as and rv commands
> for the system peer and verify the leap bits are set to 01,
> 
> As mentioned in the documentation, it is not necessary to run Autokey to
> download the leapseconds file from NIST. It is availabe via FTP from the
> pub directory and leap-seconds file.

Again, AFAIK this is true only for the developer version of NTP. 

I guess most NTP servers run a stable version, however, which (again AFAIK)
requires autokey to be enabled in order to evaluate the leap second file.
Unless I'm totally missing something the stable versions up to the current
one do not even provide a way to download that file by itself but need
manual intervention to copy the file to the right location.

As I've already posted earlier in this NG people should tell to which
version they are referring if they explayin things which have undergone
basic changes like the leap second handling.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

David,

David J Taylor wrote:
> Unruh wrote:
> []
>> From reading the ntp docs, it seems that if you download the
>> leapseconds file, call it /etc/ntp.leapseconds  and restart ntpd,
>> then ntpd will read that file, and set the leapsecond flag on your
>> system in the last month or day.
> []

Again, the text above refers to the developeer version *only*. 
 
> This seems a lot simpler than the method described in the docs:
> 
>   http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.13.
> 
> which talk about "crypto directory" and "autokey", and seem (to me) a lot
> more complicated than just copying a renamed file and restarting ntpd!

You are right. However, this is how NTP up to the current stable version
works.

> There is also the remark: "If the top level NTP server is unable to obtain
> the leap second file automatically...".  Does this mean that NTP will try
> and fetch this file by itself?

Maybe the dev version. AFAIK no stable version does so.

BTW, you can see if the leap file has been evaluated by running 

ntpq -c rv

and checking the "tai=" value. The NIST leap second file does not only
contain information about the nearest leap second but also about all
earlier leap seconds and thus allows the NTP daemon to compute the
difference between UTC and TAI.

So if the tai value is 0 then the leap file has *not* been evaluated. If the
leap file has been evaluated the displayed value is currently 33.

> Some clarification would be appreciated.

HTH,

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

David,

David J Taylor wrote:
> David L. Mills wrote:
>> David,
>>
>> In the NTPv3 spec the leap bits are to be set on the day of the leap.
>> This is compliant with the new NTPv4 spec; that spec is more liberal
>> in order to support and prioritize leap warnings when multiple means
>> are available. In cases where the radio delivers a timecode via
>> serial port, some radios include provisions for leap warning; some do
>> not. I don't know if an NMEA sentence has provisions for that. There
>> are no provisions for leap warning in IRIG devices I have.
>>
>> I  don't know if the Meinberg GPS or EndRun CDMA receiver include
>> provisions for leap warning. If so, it should appear in the NTP header
>> on the day of the leap. Both receivers use an embedded Linux system
>> which in principle has the same provisions as the public
>> distribution..

Dave,

please see my other reply or 
http://www.meinberg.de/english/info/ntp.htm
to see how Meinberg devices work.

> Thanks, Dave.  I don't know about the NMEA sentence either, but I don't
> recall seeing that possibility.  On my GPS-based server, it does also have
> Internet sources, but even though one of those sources is showing the leap
> bit, my server is not.

I'm not sure about this, but maybe it depends on the classification of an
upstream server (whether it is in the surving group of ppeers after the
selection algorithm) whether the leap second announcement is accepted, or
not.

> I'll have to check on December 31st.  It will be 
> disappinting if I have similar problems to last time!
> 
>   http://www.satsignal.eu/ntp/ntp-events.htm#leapsecond
> 
> In view of the popularity of the GPS18-LVC it's a pity that the driver
> support for the leap second isn't better, but I appreciate that being able
> to test once every few years doesn't make things any easier!

There is a complete chain which needs to be able to propagate the
announcement of a leap second.

- From the GPS satellites to the receiver

- The receiver must output a time string format which supports
  leap second announcements, and must set the announcement correctly

- NTP's driver for that device must evaluate the announcement in the
  string correctly and pass it on to the NTP kernel

If you are not sure whether the whole chain you're using supports leap
second announcements correctly you should install and use the NIST leap
second file on your server(s).

If you discuss ways to announce leap seconds you also have to distinguis the
*way* leap seconds are announced.

E.g. both the GPS satellites and the NIST leap second file do not only
announce an upcoming leap second, they also contain information *when* the
leap second will occur, so unless there is a software bug which does the
evaluation wrong you could start to announce the leap second as soon as the
IERS has published this.

If there's just an announcement flag (like the leap bit in the NTP packet)
that bit should should not be set until the moment of leap second insertion
is unambiguous.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[]
> BTW, you can see if the leap file has been evaluated by running
>
> ntpq -c rv
>
> and checking the "tai=" value. The NIST leap second file does not only
> contain information about the nearest leap second but also about all
> earlier leap seconds and thus allows the NTP daemon to compute the
> difference between UTC and TAI.
>
> So if the tai value is 0 then the leap file has *not* been evaluated.
> If the leap file has been evaluated the displayed value is currently
> 33.
>
>> Some clarification would be appreciated.
>
> HTH,
>
> Martin

Thanks, Martin.

The NTP I have running, and which has been working fine since it was 
installed, is 4.2.0-a.  There is no "tai=" value reported, so I guess it's 
just too old.  As I have no knowledge of "crypto", nor do I have a more 
recent version of NTP for FreeBSD 5.4, nor do I know whether the current 
development version works on FreeBSD 5.4, nor do I wish to try a 
development rather than a stable release on that system, I suspect I will 
just leave it as it is, and moan (to myself) on Thursday, Jan 01!

BTW: that box is a Pentium 133 with 48MB of memory.  Recompiling the OS is 
an overnight job....

Danke,
David 

David,

To verify your assumption, see rackety.udel.edu or pogo.udle.edu. The 
Spectracom driver shows leap 01, as does the PPS driver. However, in 
order to comply with NTPv3, the server itself does not show leap 01, 
even if other upstream servers show 01. The proof will be available only 
on the day of the leap.

When a leap event is ccheduled, the EVNT_ARMED event/protostats/syslog 
trap is raised. When it is descheduled, like when the upstream leap bits 
are set and then reset, the EVNT_DISARMED event is raised. You should 
see that at the appropriate places.

Dave

David J Taylor wrote:

>Unruh wrote:
>  
>
>>"David J Taylor"
>>    
>>
>[]
>  
>
>>>In view of the popularity of the GPS18-LVC it's a pity that the
>>>driver support for the leap second isn't better, but I appreciate
>>>that being able to test once every few years doesn't make things any
>>>easier!
>>>      
>>>
>>As far as I can see, the GPS18-LVC unit does NOT warn of leapseconds.
>>There is absolutely nothing the driver can do if the information is
>>not supplied by
>>the GPS unit.
>>    
>>
>
>Yes, that was poorly worded - I meant "shouldn't NTP note the leap-second 
>flags from the other Internet upstream servers, and base its whole second 
>values on those sources during a leap-second update, using just the PPS 
>part of the GPS signal?"  The would appear to apply to any GPS source 
>which is PPS + NMEA....
>
>David 
>
>_______________________________________________
>questions mailing list
>questions@lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>

Martin,

I've had a really hard time with the state of the release/dev versions, 
but I don't manage that. The release version has a date of August this 
year, but the protocol module is dated August 2006. I spent a whole year 
beginning in June 2007 making major changes, fixes and improvements, but 
they have not appeared in the current release. All I can say is that my 
comments apply to the development version and that the release version 
is on a different maintenance track. I assume, but cannot confirm, that 
the docuemtation in the release version applies specifically to that 
version. The documentaiton in the current development version is on the 
web and is regularly updated (as of last night in fact). The 
documentation in other places may or may not conform to reality.

Dave

Martin Burnicki wrote:

>Dave,
>
>David L. Mills wrote:
>  
>
>>Guys,
>>
>>See http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap for what
>>actually is in the implementation. 
>>    
>>
>
>... which is valid for the current developer version, NTP 4.2.5p[something],
>but must not necessarily match the current (or earlier) stable versions,
>i.e. NTP 4.2.4p5 and earlier.
>
>  
>
>>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.  
>>    
>>
>
>... yet. Of course the Meinberg GPS receiver is aware of the upcoming leap
>second, and it will set the leap second announcement flag a certain
>interval before the time the leap second is actually inserted.
>
>The interval depends on the firmware version. It is 59 minutes in older
>firmware versions (due to compatibility with the German longwave
>transmitter DCF77) and has been extended in recent versions to 1 day if the
>Uni Erlangen string format is used.
>
>  
>
>>The USNO and NIST servers do not show leap bits in the VME 
>>or ACTS associations, but that might not be significant until the day
>>before the leap. Our servers pogo.udel.edu and rackety.udel.edu are
>>correctly configure and the leap warning bits in the driver associations
>>correctly set. To check a server near you, run ntpq, as and rv commands
>>for the system peer and verify the leap bits are set to 01,
>>
>>As mentioned in the documentation, it is not necessary to run Autokey to
>>download the leapseconds file from NIST. It is availabe via FTP from the
>>pub directory and leap-seconds file.
>>    
>>
>
>Again, AFAIK this is true only for the developer version of NTP. 
>
>I guess most NTP servers run a stable version, however, which (again AFAIK)
>requires autokey to be enabled in order to evaluate the leap second file.
>Unless I'm totally missing something the stable versions up to the current
>one do not even provide a way to download that file by itself but need
>manual intervention to copy the file to the right location.
>
>As I've already posted earlier in this NG people should tell to which
>version they are referring if they explayin things which have undergone
>basic changes like the leap second handling.
>
>Martin
>  
>

Martin,

Correct. The ntpd (development version) does all that. However, there 
are concerns about protocol spoofing and other vulneabilities. First, 
the only upstream candidates considered are the survivors of the 
mitigation algorithms, generally three candidates. If a reference clock 
is among them, only its leap bits are used. If not, a vote is taken 
amoung the survivors and the majority is used. If two out of the three 
show leap, the result is leap. It two out of the three show no leap, the 
result is no leap.

The older code is very vulnerable to a terrorist showing leap or failing 
to pass on leap warnings received from upstream servers. The Autokey 
design was initended to reduce this vulnerability. I suspect the actual 
behavior with most servers using only the older code will not support 
leap warming due to driver or radio shortcomings. If this is the case, 
the voting scheme will fail to show the warning. There;s not much that 
can be done about that other than to upgrade to the development version 
and use either the leapseconds file or Autokey.

It gets worse. What happens if the leapseconds file is present along 
with Autokey and upstream leap warnings. Most of the time the file takes 
precedence and the other warnings are ignored. However, if Autokey shows 
leapsecond values newer than the file, then those values take 
precedence. If either the file or Autokey is present, upstream wabrings 
are ignored. On the other hand, if upstream warnings are in play, the 
leap bit vote can change with the server warning as the result. Finally, 
and with this you should understand the complexity of the scheme, what 
happens if the host time is changed significantly by the NTP protocol 
itself? Thus, the priorities are redetermined each time the clock is 
updated.

Dave

Martin Burnicki wrote:

>David,
>
>David J Taylor wrote:
>  
>
>>David L. Mills wrote:
>>    
>>
>>>David,
>>>
>>>In the NTPv3 spec the leap bits are to be set on the day of the leap.
>>>This is compliant with the new NTPv4 spec; that spec is more liberal
>>>in order to support and prioritize leap warnings when multiple means
>>>are available. In cases where the radio delivers a timecode via
>>>serial port, some radios include provisions for leap warning; some do
>>>not. I don't know if an NMEA sentence has provisions for that. There
>>>are no provisions for leap warning in IRIG devices I have.
>>>
>>>I  don't know if the Meinberg GPS or EndRun CDMA receiver include
>>>provisions for leap warning. If so, it should appear in the NTP header
>>>on the day of the leap. Both receivers use an embedded Linux system
>>>which in principle has the same provisions as the public
>>>distribution..
>>>      
>>>
>
>Dave,
>
>please see my other reply or 
>http://www.meinberg.de/english/info/ntp.htm
>to see how Meinberg devices work.
>
>  
>
>>Thanks, Dave.  I don't know about the NMEA sentence either, but I don't
>>recall seeing that possibility.  On my GPS-based server, it does also have
>>Internet sources, but even though one of those sources is showing the leap
>>bit, my server is not.
>>    
>>
>
>I'm not sure about this, but maybe it depends on the classification of an
>upstream server (whether it is in the surving group of ppeers after the
>selection algorithm) whether the leap second announcement is accepted, or
>not.
>
>  
>
>>I'll have to check on December 31st.  It will be 
>>disappinting if I have similar problems to last time!
>>
>>  http://www.satsignal.eu/ntp/ntp-events.htm#leapsecond
>>
>>In view of the popularity of the GPS18-LVC it's a pity that the driver
>>support for the leap second isn't better, but I appreciate that being able
>>to test once every few years doesn't make things any easier!
>>    
>>
>
>There is a complete chain which needs to be able to propagate the
>announcement of a leap second.
>
>- From the GPS satellites to the receiver
>
>- The receiver must output a time string format which supports
>  leap second announcements, and must set the announcement correctly
>
>- NTP's driver for that device must evaluate the announcement in the
>  string correctly and pass it on to the NTP kernel
>
>If you are not sure whether the whole chain you're using supports leap
>second announcements correctly you should install and use the NIST leap
>second file on your server(s).
>
>If you discuss ways to announce leap seconds you also have to distinguis the
>*way* leap seconds are announced.
>
>E.g. both the GPS satellites and the NIST leap second file do not only
>announce an upcoming leap second, they also contain information *when* the
>leap second will occur, so unless there is a software bug which does the
>evaluation wrong you could start to announce the leap second as soon as the
>IERS has published this.
>
>If there's just an announcement flag (like the leap bit in the NTP packet)
>that bit should should not be set until the moment of leap second insertion
>is unambiguous.
>
>Martin
>  
>

David L. Mills wrote:
> David,
>
> To verify your assumption, see rackety.udel.edu or pogo.udle.edu. The
> Spectracom driver shows leap 01, as does the PPS driver. However, in
> order to comply with NTPv3, the server itself does not show leap 01,
> even if other upstream servers show 01. The proof will be available
> only on the day of the leap.
>
> When a leap event is ccheduled, the EVNT_ARMED event/protostats/syslog
> trap is raised. When it is descheduled, like when the upstream leap
> bits are set and then reset, the EVNT_DISARMED event is raised. You
> should see that at the appropriate places.
>
> Dave

Thanks for that, Dave.  Yes, the pogo.udel.edu server shows no 
leap-second, so that's an encouragement.  I'll be back on December 31 to 
check what /my/ rather older version does!

Cheers,
David 

"David J Taylor" <david-taylor@blueyonder.neither-this-part.nor-this-bit.co.uk> writes:

>Unruh wrote:
>> "David J Taylor"
>[]
>>> In view of the popularity of the GPS18-LVC it's a pity that the
>>> driver support for the leap second isn't better, but I appreciate
>>> that being able to test once every few years doesn't make things any
>>> easier!
>>
>> As far as I can see, the GPS18-LVC unit does NOT warn of leapseconds.
>> There is absolutely nothing the driver can do if the information is
>> not supplied by
>> the GPS unit.

>Yes, that was poorly worded - I meant "shouldn't NTP note the leap-second 
>flags from the other Internet upstream servers, and base its whole second 
>values on those sources during a leap-second update, using just the PPS 
>part of the GPS signal?"  The would appear to apply to any GPS source 
>which is PPS + NMEA....

That is what it appears to do. I have three sources, a GPS PPS source (via
the shm driver which has no leapsecond warning), and two outside sources,
one a level 1 and the other a level 2 source (which is a pretty flakey
source, and is never the preferred source) The other level 1 source,
although separated from me by 45ms round trip has an offset at the .1ms
level (as compared with the PPS)

And my system is showing the leap second warning. 


ntpq> rv
assID=0 status=4964 leap_add_sec, sync_telephone, 6 events,
event_peer/strat_chg,
version="ntpd 4.2.4p4@1.1520-o Fri Mar 14 06:59:25 UTC 2008 (1)",
processor="i686", system="Linux/2.6.24.7-desktop-2mnb", leap=01,
stratum=1, precision=-20, rootdelay=0.000, rootdispersion=0.433,
peer=48639, refid=PPS,
reftime=ccf27d17.96467b01  Tue, Dec 16 2008 11:16:39.587, poll=4,
clock=ccf27d25.491436a5  Tue, Dec 16 2008 11:16:53.285, state=4,
offset=0.009, frequency=212.452, jitter=0.001, noise=0.001,
stability=0.000, tai=0





>David 

Martin Burnicki <martin.burnicki@meinberg.de> writes:

>David,

>David J Taylor wrote:
>> Unruh wrote:
>> []
>>> From reading the ntp docs, it seems that if you download the
>>> leapseconds file, call it /etc/ntp.leapseconds  and restart ntpd,
>>> then ntpd will read that file, and set the leapsecond flag on your
>>> system in the last month or day.
>> []

>Again, the text above refers to the developeer version *only*. 
> 
>> This seems a lot simpler than the method described in the docs:
>> 
>>   http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.13.
>> 
>> which talk about "crypto directory" and "autokey", and seem (to me) a lot
>> more complicated than just copying a renamed file and restarting ntpd!

>You are right. However, this is how NTP up to the current stable version
>works.

>> There is also the remark: "If the top level NTP server is unable to obtain
>> the leap second file automatically...".  Does this mean that NTP will try
>> and fetch this file by itself?

>Maybe the dev version. AFAIK no stable version does so.

>BTW, you can see if the leap file has been evaluated by running 

>ntpq -c rv

>and checking the "tai=" value. The NIST leap second file does not only
>contain information about the nearest leap second but also about all
>earlier leap seconds and thus allows the NTP daemon to compute the
>difference between UTC and TAI.

As in my previous post, my ntp (4.2.4p4) running with a local shm refclock
which gives it the PPS from my Garmin 18LVC, a remote level 1 source, and a
remote level 2 sever, has tai=0 but has the leap flag set ( certainly not
from my Garmin receiver).
Of course I did NOT have the leapseconds file installed when I started
ntpd.




 

>So if the tai value is 0 then the leap file has *not* been evaluated. If the
>leap file has been evaluated the displayed value is currently 33.

>> Some clarification would be appreciated.

>Martin

Thanks for the clarification.

I assume that there is some special sentences other than the NMEA sentences
which the Meinberg gps receiver uses to deliver the leap second warning. 

David L. Mills wrote:

> mitigation algorithms, generally three candidates. If a reference clock 
> is among them, only its leap bits are used. If not, a vote is taken 

Surely that needs to be limited to reference clocks that are definitely 
capable of reporting leap seconds without manual intervention, and 
considering the hardware, as well as the driver.

The NTP documentation published at UDel is for Dave's latest code.

I periodically check Dave's ntp-dev repository and commit/publish any
changes he has made to the code, and also similarly his ntp html/ tree.

Searchable and browsable documentation for the current -dev release as well
as the versions published with a number of previous releases (going back to
3-5.93e) is available at http://doc.ntp.org .

As for the release of ntp-4.2.6, I'll be making an announcement soon.
-- 
Harlan Stenn <stenn@ntp.org>
http://ntpforum.isc.org  - be a member!

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:

>David L. Mills wrote:

>> mitigation algorithms, generally three candidates. If a reference clock 
>> is among them, only its leap bits are used. If not, a vote is taken 

>Surely that needs to be limited to reference clocks that are definitely 
>capable of reporting leap seconds without manual intervention, and 
>considering the hardware, as well as the driver.

It also seems to be wrong for 4.2.4p4. I have an shm PPS source, which certainly does
not report leap seconds. But my system is reporting that it is leap second
ready and that could only have come from its other two servers, which are
not refclock drivers, but standard network servers. 

David,

More specifically, for those survivors that show leap warnings, a 
counter is incremented. If any survivoe, referencde clock or not, does 
not show warning the ocunter is not incremented. For refclocks the 
counter is set to the number of survivors, but only if the warning is 
lit. After this, if the counter is greater than half the number of 
survivors, the system leap warning is lit. You are welcdome to suggest 
an alternative method on the basis that some refclocks do not implement 
the leap warning and others may show a warning in error.

Dave

David Woolley wrote:

>David L. Mills wrote:
>
>  
>
>>mitigation algorithms, generally three candidates. If a reference clock 
>>is among them, only its leap bits are used. If not, a vote is taken 
>>    
>>
>
>Surely that needs to be limited to reference clocks that are definitely 
>capable of reporting leap seconds without manual intervention, and 
>considering the hardware, as well as the driver.
>
>_______________________________________________
>questions mailing list
>questions@lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>

David L. Mills wrote:
> David,
> 
> More specifically, for those survivors that show leap warnings, a 
> counter is incremented. If any survivoe, referencde clock or not, does 
> not show warning the ocunter is not incremented. For refclocks the 
> counter is set to the number of survivors, but only if the warning is 
> lit. After this, if the counter is greater than half the number of 
> survivors, the system leap warning is lit. You are welcdome to suggest 
> an alternative method on the basis that some refclocks do not implement 
> the leap warning and others may show a warning in error.
> 
> Dave

How about a leap minute every 240 years or so?

In article <5_qdnYFHy5W4g9TUnZ2dnUVZ_r3inZ2d@giganews.com>,
Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>David L. Mills wrote:
>> More specifically, for those survivors that show leap warnings, a 
>> counter is incremented. If any survivoe, referencde clock or not, does 
>> not show warning the ocunter is not incremented. For refclocks the 
>> counter is set to the number of survivors, but only if the warning is 
>> lit. After this, if the counter is greater than half the number of 
>> survivors, the system leap warning is lit. You are welcdome to suggest 
>> an alternative method on the basis that some refclocks do not implement 
>> the leap warning and others may show a warning in error.
>
>How about a leap minute every 240 years or so?

How would that address the issue?

Or are you saying in 240 years you won't be around to care :-)

-- 
					-- Rod --
rodd(at)polylogics(dot)com

Rod Dorman wrote:
> In article <5_qdnYFHy5W4g9TUnZ2dnUVZ_r3inZ2d@giganews.com>,
> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>> David L. Mills wrote:
>>> More specifically, for those survivors that show leap warnings, a 
>>> counter is incremented. If any survivoe, referencde clock or not, does 
>>> not show warning the ocunter is not incremented. For refclocks the 
>>> counter is set to the number of survivors, but only if the warning is 
>>> lit. After this, if the counter is greater than half the number of 
>>> survivors, the system leap warning is lit. You are welcdome to suggest 
>>> an alternative method on the basis that some refclocks do not implement 
>>> the leap warning and others may show a warning in error.
>> How about a leap minute every 240 years or so?
> 
> How would that address the issue?
> 
> Or are you saying in 240 years you won't be around to care :-)
> 

Exactly!!   Dump the problem on our ten/eleven-times greatgrandchildren!

Leap seconds?  Who needs them???????

Ninetynine percent of the clocks in the world are already off by more 
than one seconds.  Half of them will be a second more off and the other 
half will be, briefly, one second closer to being right.

moreiras@nic.br (Antonio M. Moreiras) writes:

>So, if I understand, I have to:

>1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400
>2 - rename the file to ntp.leapseconds and put it in /etc
>3 - stop and start ntpd
>4 - verify the warning bits

And it sounds like you should also make sure that you are running the
development version of ntp.

Alternatively, make sure that you have a majority of your servers as ntp
sources which have the leapseconds bit set.


>It should be done at primary servers and the others would get
>automatically the file if using autokey.

>It could be done also at any stratum if one don't trust the references
>regarding this issue.

>Don't having the file, and if not using autokey and references with the
>information, the client will relay at information from the majority of
>survivor references. If they warn the leapsecond, the client will get it
>correctly.

>Is this correct?


All I can say is that om my machine which has one PPP source (no leapsecond
warning) and two external servers (one stratum 1 tick.usask.ca and the other
stratum 2 ntp.ubc.ca), my machine has the leapsecond warning bit set.  

>David L. Mills escreveu:
>> Guys,
>> 
>> See http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap for what 
>> actually is in the implementation. (...)
>> As mentioned in the documentation, it is not necessary to run Autokey to 
>> download the leapseconds file from NIST. It is availabe via FTP from the 
>> pub directory and leap-seconds file.
>> 
>> Dave
>> 

Unruh wrote:
> As in my previous post, my ntp (4.2.4p4) running with a local shm refclock
> which gives it the PPS from my Garmin 18LVC, a remote level 1 source, and
> a remote level 2 sever, has tai=0 but has the leap flag set ( certainly
> not from my Garmin receiver).
> Of course I did NOT have the leapseconds file installed when I started
> ntpd.

So it seems the leap flag has been received from the upstream NTP server.

As I've already mentioned earlier I think ntpd should generate a log message
by default (not only if explicitely configured) when it receives a leap
second announcement, and from which source the announcement is received.

> I assume that there is some special sentences other than the NMEA
> sentences which the Meinberg gps receiver uses to deliver the leap second
> warning.

Maybe. I'm not too familiar with NMEA since the Meinberg GPS clocks mostly
use a different time string format which is compatible with our DCF77
receivers, which have already been existing before the first GPS clocks
became available.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Unruh wrote:
> David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
> 
>>David L. Mills wrote:
> 
>>> mitigation algorithms, generally three candidates. If a reference clock
>>> is among them, only its leap bits are used. If not, a vote is taken
> 
>>Surely that needs to be limited to reference clocks that are definitely
>>capable of reporting leap seconds without manual intervention, and
>>considering the hardware, as well as the driver.
> 
> It also seems to be wrong for 4.2.4p4. I have an shm PPS source, which
> certainly does not report leap seconds. But my system is reporting that it
> is leap second ready and that could only have come from its other two
> servers, which are not refclock drivers, but standard network servers.

Again, what Dave has pointed out refers only to the dev version. 4.2.4p4 is
a stable version which behaves differently.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Antonio M. Moreiras wrote:
> So, if I understand, I have to:
> 
> 1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400
> 2 - rename the file to ntp.leapseconds and put it in /etc
> 3 - stop and start ntpd
> 4 - verify the warning bits

As Unruh has already mentioned, only if you use the dev version. Otherwise
you should do what is described under the link I've posted earlier.

Maybe you should tell us which version(s) of NTP you are running.

> It should be done at primary servers and the others would get
> automatically the file if using autokey.

Even if they don't use autokey the others would receive the leap second
warning via the leap bits in the standard protocol.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Hi there


Antonio M. Moreiras wrote:

<Cut>

> 1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400

Is there an other source?
This site appears to be down.

<Cut>


Regards,
Rob

>> 1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400
>
>Is there an other source?
>This site appears to be down.

That site is unlikely to be down for long.

Are you behind a NAT box?  I need to use the passive mode for ftp.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.

>Maybe. I'm not too familiar with NMEA since the Meinberg GPS clocks mostly
>use a different time string format which is compatible with our DCF77
>receivers, which have already been existing before the first GPS clocks
>became available.

I haven't been able to find any NMEA documentation that describes
a future leap second.  The ZDA sentence does tell you the offset
between GPS time and UTC.  By watching that you could tell when
a leap second had just happened, but then it's too late to do
anything.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Martin,

The current version sends a message to the system log, protostats log 
and trap (if configured) when the leap is armed, disarmged or executed.

Dave

Martin Burnicki wrote:

>Unruh wrote:
>  
>
>>As in my previous post, my ntp (4.2.4p4) running with a local shm refclock
>>which gives it the PPS from my Garmin 18LVC, a remote level 1 source, and
>>a remote level 2 sever, has tai=0 but has the leap flag set ( certainly
>>not from my Garmin receiver).
>>Of course I did NOT have the leapseconds file installed when I started
>>ntpd.
>>    
>>
>
>So it seems the leap flag has been received from the upstream NTP server.
>
>As I've already mentioned earlier I think ntpd should generate a log message
>by default (not only if explicitely configured) when it receives a leap
>second announcement, and from which source the announcement is received.
>
>  
>
>>I assume that there is some special sentences other than the NMEA
>>sentences which the Meinberg gps receiver uses to deliver the leap second
>>warning.
>>    
>>
>
>Maybe. I'm not too familiar with NMEA since the Meinberg GPS clocks mostly
>use a different time string format which is compatible with our DCF77
>receivers, which have already been existing before the first GPS clocks
>became available.
>
>Martin
>  
>

Rob,

I am told the file is on all NTP servers operated by NIST. See the list 
of public servers at NIST or www.ntp.org.

Dave

Rob van der Putten wrote:

>Hi there
>
>
>Antonio M. Moreiras wrote:
>
><Cut>
>
>  
>
>>1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400
>>    
>>
>
>Is there an other source?
>This site appears to be down.
>
><Cut>
>
>
>Regards,
>Rob
>
>_______________________________________________
>questions mailing list
>questions@lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>

Hi there


Hal Murray wrote:

> That site is unlikely to be down for long.

It's still down.
I can ping time.nist.gov, but it won't FTP.

> Are you behind a NAT box?  I need to use the passive mode for ftp.

No.
I also tried the shell box at my ISP.
Same result.


Regards,
Rob

Hi there


David L. Mills wrote:

> I am told the file is on all NTP servers operated by NIST. See the list 
> of public servers at NIST or www.ntp.org.

ftp://ntp-a.boulder.nist.gov/pub/leap-seconds.3427142400 works
Thanks!


Regards,
Rob

On 19 dez, 09:43, Rob van der Putten <r...@sput.nl> wrote:
> Hi there
>
> David L. Mills wrote:
> > I am told the file is on all NTP servers operated by NIST. See the list
> > of public servers at NIST orwww.ntp.org.
>
> ftp://ntp-a.boulder.nist.gov/pub/leap-seconds.3427142400works
> Thanks!
>
> Regards,
> Rob

Hi there,

I used the below tutorial to set the leapseconds, but, the
"leap_armed" is not showed when the command "ntpq"  is executed.
I=B4m using freebsd 7.0 and the ntp version "ntp-dev-4.2.5p150". :

What can be wrong ?

Thank=B4s

############ NTPQ #################
a# ntpq -c "rv"
status=3D01fd leap_none, sync_atomic, 15 events, event_13,
version=3D"ntpd 4.2.5p150@1.1795-o Fri Dec 19 16:47:03 UTC 2008 (1)",
processor=3D"i386", system=3D"FreeBSD/7.0-RELEASE-p6", leap=3D00, stratum=
=3D1,
precision=3D-19, rootdelay=3D0.000, rootdisp=3D0.239, refid=3DPPS,
reftime=3Dccf66913.a1585ecd  Fri, Dec 19 2008 16:40:19.630,
clock=3Dccf66914.66d46964  Fri, Dec 19 2008 16:40:20.401, peer=3D49506,
tc=3D4, mintc=3D2, offset=3D0.002, frequency=3D40.487, sys_jitter=3D0.003,
clk_jitter=3D0.000, clk_wander=3D0.000, tai=3D33, leapsec=3D200901010000,
expire=3D200906280000
#################################


################## LOG #######################
# /usr/local/bin/ntpd -d -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f /
var/db/ntpd.drift
ntpd 4.2.5p150@1.1795-o Fri Dec 19 16:47:03 UTC 2008 (1)
addto_syslog: proto: precision =3D 1.396 usec
addto_syslog: ntp_io: estimated max descriptors: 11095, initial socket
boundary: 20
addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled
addto_syslog: Listening on interface #2 bce1, 200.160.7.186#123
Enabled
restrict: addr c8a007ba mask ffffffff mflags 00003000 flags 00000001
addto_syslog: Listening on interface #3 lo0, fe80::1#123 Enabled
addto_syslog: Listening on interface #4 lo0, ::1#123 Enabled
addto_syslog: Listening on interface #5 lo0, 127.0.0.1#123 Enabled
restrict: addr 7f000001 mask ffffffff mflags 00003000 flags 00000001
addto_syslog: Listening on routing socket on fd #26 for interface
updates
loop_config: item 1 freq 0.000000
event at 0 0.0.0.0 c010 0d system event: kern kernel time sync enabled
restrict: addr 00000000 mask 00000000 mflags 00000000 flags 00000192
restrict: addr c8a00300 mask ffffff00 mflags 00000000 flags 000001b0
restrict: addr c8a00500 mask ffffff00 mflags 00000000 flags 000001b0
restrict: addr c8a00100 mask ffffff00 mflags 00000000 flags 000001b0
restrict: addr c8a00780 mask ffffff80 mflags 00000000 flags 00000190
restrict: addr c8ba7dc8 mask ffffffff mflags 00000000 flags 000001b0
restrict: addr c8a00001 mask ffffffc0 mflags 00000000 flags 000001b0
restrict: addr c8bd2801 mask ffffffc0 mflags 00000000 flags 000001b0
restrict: addr c8c0e801 mask ffffffc0 mflags 00000000 flags 000001b0
restrict: addr c814ba5e mask ffffffff mflags 00000000 flags 000001b0
restrict: addr c814ba4b mask ffffffff mflags 00000000 flags 000001b0
restrict: addr c8a007a5 mask ffffffff mflags 00000000 flags 000001b0
restrict: addr c8137778 mask ffffffff mflags 00000000 flags 000001b0
restrict: addr 8f6bff0f mask ffffffff mflags 00000000 flags 000001b0
restrict: addr c02bf412 mask ffffffff mflags 00000000 flags 000001b0
restrict: addr c00529d1 mask ffffffff mflags 00000000 flags 000001b0
restrict: addr c814ba4b mask ffffffff mflags 00000000 flags 000001b0
addto_syslog: leap epoch 3439756800 expire 3455136000 TAI offset 34
from /etc/ntp.leap
addto_syslog: set_peerdstadr(127.127.6.0): change interface from
<null> to 127.0.0.1
key_expire: at 0 associd 28259
peer_clear: at 0 next 1 associd 28259 refid INIT
audio_config_read: reading </etc/ntp.audio0>
idev </dev/audio0.0>
cdev </dev/mixer0>
agc <line> 12
monitor <vol> 0
audio_init: </dev/audio0.0> bufsiz 320
audio_init: orig: play_size 128, rec_size 128
audio_init: want: play_size 320, rec_size 320
audio_init: set:  play_size 128, rec_size 128
audio_init: play_rate 8000, rec_rate 8000, play_format 0x1, rec_format
0x1
audio_show: ctl_fd 6
event at 0 IRIG_AUDIO(0) 8011 81 peer event: mobilize assoc 28259
newpeer: 127.0.0.1->127.127.6.0 mode 3 vers 4 poll 4 4 flags 0xa9 0x1
ttl 0 key 00000000
addto_syslog: set_peerdstadr(127.127.22.0): change interface from
<null> to 127.0.0.1

################## TUTORIAL ##################
1) Download to /etc the NIST leapseconds file leap-seconds.3427142400
   (or the latest) from ftp://time.nist.gov/pub/ by passive ftp. Then
   make a symlink from the generic name ntp.leap to the file:

| # cd /etc/
| # wget --passive-ftp ftp://time.nist.gov/pub/leap-seconds.3427142400
| # ln -s leap-seconds.3427142400 ntp.leap


2) Add to /etc/ntp.conf this line:

| leapfile /etc/ntp.leap


3) Restart the NTP daemon. After it is synced, you can verify all
worked
   well using the ntpq readvar command, by checking the current TAI
   offset, looking at the date of the (future) leap event, and at the
   validity limit of the leapfile:

| $ ntpq -c "rv 0 leap,tai,leapsec,expire"
| associd=3D0 status=3D0259 leap_none, sync_lf_radio, 5 events,
leap_armed,
| leap=3D00, tai=3D33, leapsec=3D200901010000, expire=3D200906280000
######################################