From owner-svn-src-all@freebsd.org Tue Oct 20 15:35:04 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 184EFA1905A for ; Tue, 20 Oct 2015 15:35:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBB34173 for ; Tue, 20 Oct 2015 15:35:03 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 20 Oct 2015 15:34:43 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t9KFYxjI012863; Tue, 20 Oct 2015 09:35:00 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1445355299.99375.16.camel@freebsd.org> Subject: Re: svn commit: r289421 - in head/etc: . mtree ntp From: Ian Lepore To: David Malone Cc: Cy Schubert , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Tue, 20 Oct 2015 09:34:59 -0600 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> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 15:35:04 -0000 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