On Wed, 07 Mar 2007 10:01:02 +0100, Martin Burnicki <[EMAIL PROTECTED]> wrote:
>So if none of the upstream servers sends the announcement anymore, the local >ntpd just seems to "forget" the announcement it has seen before. However, >I'll have a closer look at this. This is partly because of the ambiguity of the NTP leap bits. leap=00 means either "no leap at next available opportunity" or "don't know" and the client has no way of knowing what to do if it's fed both 0s and 1s. Is there definitely a leap-second event on the way but one server doesn't know about it yet, or are the two servers positively contradicting each other? >Basically, leap second might be added or subtracted at the end of any month, >but preferably this should be done at the end of June or December, and if >required at a shorter interval it should be at the end of March or >September. > >I rememeber there have been invalid leap second announcements for end of >September 2005 which came from a GPS receiver (not Meinberg ;-) which "saw" >the leap second announcement from GPS for end of December, 2005, but did >not evaluate the insertion date correctly. > >So end of March is also a candidate for faulty announcements, even though >there's currently no pending leap second announcement. I wish the GPS operators would flag for upcoming leap-seconds no more than 3 months in advance of the event, in order to prevent just this sort of ambiguity. I don't know of any GPS receiver which outputs the date/time of the next leap second event; all they ever do is raise a binary flag. If the GPS signal in space says, in February, that the next leap second is at 24:00 30 June, the receivers all dumb-down the message to "leap second on the way". The poor user is left to guess whether it's in March or June. Any time lords willing to confront the US military on this? _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
