[ntp:questions] WARNING: someone's faking a leap second tonight
jeffrey.lerman at gmail.com
Fri Aug 3 21:37:42 UTC 2012
Oh, my mistake: I quote RFC5905 below, which is for NTPv4, which is
technically in _draft_ status - though it does seem pretty far along and
I believe current ntpd adheres to NTPv4, not v3.
For what it's worth the most recently approved protocol is, technically,
NTPv3, documented in RFC1305 - and that one does say "current day" -
though again, ntpd respects the end-of-month rule.
David Mills' website includes this page:
There one can see two things:
- The idea to let the leap-seconds file override all else when it's
present is already apparently implemented. Good.
- This text:
"When an update is received from a reference clock or downstratum
server, the leap bits are inspected for all survivors of the cluster
algorithm. If the number of survivors showing a leap bit is greater
than half the total number of survivors, a pending leap condition
exists until the end of the current month."
Hmm. No mention of clearing the bit if an update is received that does
NOT show a leap bit. I wonder if that's the problem in a nutshell. Can
anyone demonstrate whether ntpd clears the bit if it is set but an
upstream server is configured and sends an LI=00 update?
On 8/3/2012 2:04 PM, Jeffrey Lerman wrote:
> That page appears to be out-of-date. The current protocol, for NTP
> version 4, is here: http://www.ietf.org/rfc/rfc5905.txt
> Note that there was a change from the earlier version, which did say
> "current day". Also, the LI ("Leap Indicator") field is only used to
> indicate presence/absence of an impending leap second.
> The current doc says in part:
> The fields and associated packet variables (in parentheses) are
> interpreted as follows:
> LI Leap Indicator (leap): 2-bit integer warning of an impending leap
> second to be inserted or deleted in the last minute of the_*current
> month*_with values defined in Figure 9.
> | Value | Meaning |
> | 0 | no warning |
> | 1 | last minute of the day has 61 seconds |
> | 2 | last minute of the day has 59 seconds |
> | 3 | unknown (clock unsynchronized) |
> Figure 9: Leap Indicator
> Technically, there should be no need for the 2-week buffer I
> suggested. However, it shouldn't hurt, and seems likely to add
> robustness. The true correct solution would be to ensure that ntpd
> clients pay as much attention to LI=00 from a server as to LI != 00
> (and to fix the bug Martin filed, in which the LI field goes to 00 in
> the last second BEFORE the leap second - oops). Then they would be
> able to recover gracefully from a brief persistence of the LI=01 value
> past the leap second - assuming that no stratum 1 servers erroneously
> persisted the LI value. We really need to understand why that is
> happening - do we have version info from the servers that are still
> doing that?
> Another suggestion... Should ntpd require that a stratum-1 server has
> a non-expired leap-second file, and that that file should override any
> upstream server for the LI data?
> On 8/3/2012 11:48 AM, E-Mail Sent to this address will be added to the
> BlackLists wrote:
>> Martin Burnicki wrote:
>>>> clients to independently set LI=00 during, say the first
>>>> half of the month, and to ignore the LI value from
>>>> servers during that time.
>> I think you would have to be more exact than that.
>> LI is used for more than one thing.
>> According to the doc, LI only applies to the current day?
More information about the questions