From owner-freebsd-hackers@freebsd.org Thu Sep 24 14:24:37 2015 Return-Path: Delivered-To: freebsd-hackers@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 402C6A08DE4 for ; Thu, 24 Sep 2015 14:24:37 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 255241B60 for ; Thu, 24 Sep 2015 14:24:37 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 23CB1A08DE3; Thu, 24 Sep 2015 14:24:37 +0000 (UTC) Delivered-To: hackers@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 099C2A08DE2 for ; Thu, 24 Sep 2015 14:24:37 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 D393D1B5E for ; Thu, 24 Sep 2015 14:24:36 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 24 Sep 2015 14:24:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t8OENRuu003304; Thu, 24 Sep 2015 08:23:27 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1443104607.1224.265.camel@freebsd.org> Subject: Re: What IS the right NTP behaviour ? From: Ian Lepore To: Dirk-Willem van Gulik Cc: Erik Cederstrand , FreeBSD Hackers Date: Thu, 24 Sep 2015 08:23:27 -0600 In-Reply-To: <05581AEE-5A92-49B0-8F35-FE96BE15CF2A@webweaving.org> References: <39337.1442999127@critter.freebsd.dk> <20150923192729.GB78209@numachi.com> <0CAEE340-B9DF-4772-8600-8A0904636452@cederstrand.dk> <05581AEE-5A92-49B0-8F35-FE96BE15CF2A@webweaving.org> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 14:24:37 -0000 On Thu, 2015-09-24 at 11:27 +0200, Dirk-Willem van Gulik wrote: > On 24 Sep 2015, at 11:12, Erik Cederstrand wrote: > > > >> Den 23/09/2015 kl. 22.33 skrev dirkx@webweaving.org: > >> > >>> On 23 Sep 2015, at 21:27, Brian Reichert wrote: > >>> > >>> On Wed, Sep 23, 2015 at 11:04:43AM -0700, Brandon Vincent wrote: > >>>> On Wed, Sep 23, 2015 at 10:35 AM, Tim Kientzle wrote: > >>>>> One concern I keep running into: Using NTP in VMs that are frequently suspended/resumed. Though I suppose this may be covered by your 'workstation' scenario (just step it after VM resume when you see the large skew). > >>>> > >>>> I would assume your hypervisor would sync the clock upon VM events. Does it not? > >>> > >>> In my VMs that run an NTP client, I keep the hypervisor out of the > >>> loop, and let the guest's NTP client to it's work. > >> > >>> ..http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427 > >> > >> Aye - but I’ve not found any clean way of doing that — now a small rc.d file does a stop of ntpd, an ntpdate (because the jumps are bigger than what ntpd by default will accomodate) and a restart of ntpd. > > > > Does "tinker panic 0" in /etc/ntp.conf not work for you? > > Yes and no - it would work; but we have another set of issues (largely legacy with bad security that waits for equipment to be old enough to be replaced) that wants us to have it the panic threshold set to something sensible (we set it to 10 second) as the result to a string of incidents in the past (and recent past). > > So I guess what we’d want is something like ‘tinker panic 0’. > > Dw The drawback to using tinker to allow stepping is that the logic for stepping is different at startup and after being in-sync. A startup step happens very quickly (as long as a drift frequency was obtained from a file). Once sync has been achieved a step will happen only after the stepout period has elapsed, and the default stepout period is 900 seconds iirc. You can lower that with tinker, but there's a limit to how low you can go. If you set stepout too low and your clock drift rate is high, you can end up in a situation where ntpd can never "capture" the drifting clock and steer it to be on-time. (The stepout period is effectively the time constant for the PLL.) What I've wanted more than once is the ability to "re-arm" that startup-time stepout logic programatically (like with an ntp control message using ntpq). Right now the only way I know to do that is to kill and restart ntpd. -- Ian