David, David E. Ross wrote: > On 1/26/2009 8:30 AM, David Malone wrote: >> "David E. Ross" <[email protected]> writes: >> >>> Per my earlier reply, they should be set only during the same day that >>> ends with a leap-second. >> >> Note that while some of the current RFCs say "current day" the draft >> of the NTPv4 spec at: >> >> http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-11.txt >> >> says "end of the current month". I guess this is to bring the spec >> inline with existing practice.
Since leap seconds are only to be inserted at the end of a month it shouldn't really matter whether a (valid) announcement starts at the beginning of the month or at the last day of a month. If the receiver of that announcement works correctly then the leap second should be inserted correctly. > Whether the leap-second flag means "end of the current day" (per RFCs > 1305 and 4330) or "end of the current month" (per the draft RFC for NTP > v.4), indicating a leap-second today is an error. I absolutely agree. The question is what is the reason for this error. > When such an error is > seen, it makes me question the accuracy of the affected NTP server. > After all, if they can't get the leap-second flag correct (something I > dealt with in the early 1970s before there was NTP), what else are they > doing wrong? There may be several possible reasons why an NTP server may still report a leap second announcement. For example, that particular NTP server still receives an announcement from an upstream source (NTP server or refclock). If the upstream source is a refclock then the refclock should be blamed. If the upstream source is an NTP server then the question is again, where that NTP server has received the announcement from. The question is also which version of the NTP program is running on those servers. Around the last leap second I've heard 2 reports from different people that NTP servers running release versions did not clear the leap second flag after the leap second had occurred (and inserted correctly) when the servers had been configured to peer with other servers. This seems to indicate that if a group of peers has received an announcement from an external source they pass arround the announcement to each other so it will never be cleared. Sounds like this might be what you've observed. I haven't duplicated this problem, but if it's true it's clearly a bug in ntpd, though this may pop up in certain configurations. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
