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