svn commit: r289421 - in head/etc: . mtree ntp

[Warner Losh]

> On Oct 17, 2015, at 3:20 PM, David Malone <dwmalone at maths.tcd.ie> wrote:
> 
> On Sat, Oct 17, 2015 at 12:25:50PM -0600, Ian Lepore wrote:
>>    If the leapseconds file is present, the leap bits for reference
>>    clocks and downstratum servers are ignored.
>> 
>> I can't determine from casual code examination (and I don't have time
>> to experiment now) whether that is true even if the file is expired.
> 
> The way the code seems to work is:
> 
> 	1) Take a vote from your peers on if there is an upcoming
> 	leap second. Refclocks can outvote other peers. (This is
> 	in ntp_proto.c:clock_update() - search for leap_vote_ins).

Assuming no bugs, yes. And assuming your peers are sending
the correct information. History with ntpd and ntp serves well
illustrates that these assumptions are violated often.

> 	2) If one seems to be pending, try to insert it into an
> 	in-memory table for the end of the month.

NTP only recognizes June and December as valid leap insertion
points. This is likely safe for the foreseeable future though, even
though the official standard allows leap seconds to be the end of
any month. Too many things assume you only have leap seconds
at these times for IERS to issue one that isn’t at the end of December
or June until earth rotation forces their hand sometime around the
end of this century (give or take a few decades).

> 	3) If you find that you loaded a table and the leapsecond
> 	you are trying to insert is within the valid range of the
> 	table, return an error. (This is in ntp_leapsec.c:leapsec_add())
> 
> So, I think the change should be safe, if the comments match the code.

That’s a big if. Both Ian and I have witnessed the carnage of incorrect
leap seconds first hand and so are somewhat touchy on the subject. It
is a place where getting the canonical information is 1000x better than
relying on code to implement things that can’t go wrong. Because they
often do. Way way too often. When you have leap second info, always
always always try extra hard to make sure it is as up to date as you
can get it. Any “short cut” here is asking for trouble, even if you think
you can prove that no such trouble is possible.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20151017/e53f7351/attachment.bin>