Date: Tue, 20 Oct 2015 09:34:59 -0600 From: Ian Lepore <ian@freebsd.org> To: David Malone <dwmalone@maths.tcd.ie> Cc: Cy Schubert <cy@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r289421 - in head/etc: . mtree ntp Message-ID: <1445355299.99375.16.camel@freebsd.org> In-Reply-To: <20151017212033.GA43955@walton.maths.tcd.ie> References: <201510161404.t9GE4GqM046436@repo.freebsd.org> <1445106350.71631.36.camel@freebsd.org> <20151017212033.GA43955@walton.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2015-10-17 at 22:20 +0100, David Malone 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). > > 2) If one seems to be pending, try to insert it into an > in-memory table for the end of the month. > > 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. > > David. I am slightly less worried after absorbing this info. Only slightly. The leap second is accepted if the time it arrives from the peers is later than the current expiration date in the leapfile. For some reason, nist has always set that expiration date to be 2 days before the actual leap event. That is insane, always has been. The information in that file is valid right up until the second of the leap event. I've always thought that some day they'd straighten that out and use a real expiration date. If they ever do, ntpd is going to turn into a pumpkin at midnight, because it will then reject incoming leap notification from peers right up until the second that it is too late to act on them. But, all of that is theoretical and the way things stand right now it appears to be safe to enable this. I'm probably just scared because I've been burned by leap seconds so many times, especially related to handling leapfiles and their expiration dates (and things like the corner cases that happen when a unit has been powered down for months and gets powered up 30 seconds before a leap event). -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1445355299.99375.16.camel>