> On Oct 17, 2015, at 3:20 PM, David Malone <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
