Date: Sat, 17 Oct 2015 19:00:16 -0700 From: Cy Schubert <Cy.Schubert@komquats.com> To: Warner Losh <imp@bsdimp.com> Cc: David Malone <dwmalone@maths.tcd.ie>, Ian Lepore <ian@freebsd.org>, 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: <201510180200.t9I20G3g061874@slippy.cwsent.com> In-Reply-To: Message from Warner Losh <imp@bsdimp.com> of "Sat, 17 Oct 2015 17:44:35 -0600." <00150EF2-0020-42E5-A1E5-324A23975577@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <00150EF2-0020-42E5-A1E5-324A23975577@bsdimp.com>, Warner Losh writes: > > On Oct 17, 2015, at 3:20 PM, David Malone <dwmalone@maths.tcd.ie> = > wrote: > >=20 > > 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. > >>=20 > >> 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. > >=20 > > The way the code seems to work is: > >=20 > > 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=E2=80=99t 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()) > >=20 > > So, I think the change should be safe, if the comments match the code. > > That=E2=80=99s 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=E2=80=99t 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 =E2=80=9Cshort cut=E2=80=9D here is asking for trouble, = > even if you think > you can prove that no such trouble is possible. Would an rc.conf option to use an alternate ntp.conf be of help? Having said that (and shooting down my own idea), it does seem a bit messy and rather inelegant though. -- Cheers, Cy Schubert <Cy.Schubert@komquats.com> or <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201510180200.t9I20G3g061874>