I have a question about the leap seconds indicator.  Based on my
understanding of ntp, and the html page on your site dealing with leap
seconds, http://www.cis.udel.edu/~mills/leap.html, I have been telling
my team that the leap second indicator was the only true arbiter of
whether a mode 4 reply packet was in the leap second or the subsequent
second.  Therefore, we had to ensure that the value was cleared on the
rising edge of the first second of the day following the
insertion/deletion.  So, we set up tests and I defined a control sample
which was a linux box running stock ntp distribution, v4.2.4p3@1.1502-o.
A little old but we haven't leapt in a while.   

The test setup involved a GPS simulator with a leap second scheduled
which broadcast to one of our stratum 1 boxes.  The stratum 1 was
verified to be propagating the leap insertion bit.  The control box was
synchronized to the stratum 1 and propagating the leap insertion bit.
Note that there was no autokey enabled.  We noted that the control box
did not clear the leap bit until the next poll update after the leap
event.  Do you believe this is the correct behavior?  

Is this behavior different for the latest dev tree code?

 

Greg Dowd

gdowd at symmetricom dot com (antispam format) Symmetricom, Inc.

www.symmetricom.com

"Everything should be made as simple as possible, but no simpler" Albert
Einstein

Greg,


Not true. The leap warning bit has to go away only before the end of the 
next day. Note the upstream leap bits have at least one day to go away 
as well, since they are disregarded less than 28 days before the end of 
the month..

Dave

Greg Dowd wrote:

>I have a question about the leap seconds indicator.  Based on my
>understanding of ntp, and the html page on your site dealing with leap
>seconds, http://www.cis.udel.edu/~mills/leap.html, I have been telling
>my team that the leap second indicator was the only true arbiter of
>whether a mode 4 reply packet was in the leap second or the subsequent
>second.  Therefore, we had to ensure that the value was cleared on the
>rising edge of the first second of the day following the
>insertion/deletion.  So, we set up tests and I defined a control sample
>which was a linux box running stock ntp distribution, v4.2.4p3@1.1502-o.
>A little old but we haven't leapt in a while.   
>
>The test setup involved a GPS simulator with a leap second scheduled
>which broadcast to one of our stratum 1 boxes.  The stratum 1 was
>verified to be propagating the leap insertion bit.  The control box was
>synchronized to the stratum 1 and propagating the leap insertion bit.
>Note that there was no autokey enabled.  We noted that the control box
>did not clear the leap bit until the next poll update after the leap
>event.  Do you believe this is the correct behavior?  
>
>Is this behavior different for the latest dev tree code?
>
> 
>
>Greg Dowd
>
>gdowd at symmetricom dot com (antispam format) Symmetricom, Inc.
>
>www.symmetricom.com
>
>"Everything should be made as simple as possible, but no simpler" Albert
>Einstein
>
> 
>
>
>  
>