[ntp:questions] False Reports of Leap-Seconds

Martin Burnicki martin.burnicki at meinberg.de
Tue Jan 27 08:37:17 UTC 2009


David,

David E. Ross wrote:
> On 1/26/2009 8:30 AM, David Malone wrote:
>> "David E. Ross" <nobody at nowhere.not> 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




More information about the questions mailing list