Skip site navigation (1)Skip section navigation (2)
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>