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:
http://www.eecis.udel.edu/~mills/ntp/html/leap.html
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?
--Jeff
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?
--Jeff
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.
<http://www.eecis.udel.edu/~mills/ntp/html/decode.html>
According to the doc, LI only applies to the current day?
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
