From owner-freebsd-hackers@freebsd.org Thu Sep 24 09:33:48 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 4ED08A08257 for ; Thu, 24 Sep 2015 09:33:48 +0000 (UTC) (envelope-from dirkx@webweaving.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 300AC17C1 for ; Thu, 24 Sep 2015 09:33:48 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2D990A08256; Thu, 24 Sep 2015 09:33:48 +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 1362FA08254 for ; Thu, 24 Sep 2015 09:33:48 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 979A617C0 for ; Thu, 24 Sep 2015 09:33:47 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from [10.11.0.122] (5ED29D98.cm-7-3c.dynamic.ziggo.nl [94.210.157.152]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id t8O9WSRh045967 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Sep 2015 11:32:28 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29D98.cm-7-3c.dynamic.ziggo.nl [94.210.157.152] claimed to be [10.11.0.122] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3093\)) Subject: Re: What IS the right NTP behaviour ? From: Dirk-Willem van Gulik In-Reply-To: <05581AEE-5A92-49B0-8F35-FE96BE15CF2A@webweaving.org> Date: Thu, 24 Sep 2015 11:32:28 +0200 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <2E0C3E03-127C-4765-B359-7809B4B057F0@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> To: Erik Cederstrand X-Mailer: Apple Mail (2.3093) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Thu, 24 Sep 2015 11:32:28 +0200 (CEST) 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 09:33:48 -0000 > On 24 Sep 2015, at 11:27, Dirk-Willem van Gulik = wrote: >=20 > On 24 Sep 2015, at 11:12, Erik Cederstrand = wrote: >>=20 >>> Den 23/09/2015 kl. 22.33 skrev dirkx@webweaving.org: >>>=20 >>>> On 23 Sep 2015, at 21:27, Brian Reichert = wrote: >>>>=20 >>>> 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). >>>>>=20 >>>>> I would assume your hypervisor would sync the clock upon VM = events. Does it not? >>>>=20 >>>> 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. >>>=20 >>>> = ..http://kb.vmware.com/selfservice/microsites/search.do?language=3Den_US&c= md=3DdisplayKC&externalId=3D1006427 >>>=20 >>> Aye - but I=E2=80=99ve not found any clean way of doing that =E2=80=94= 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. >>=20 >> Does "tinker panic 0" in /etc/ntp.conf not work for you? >=20 > 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). >=20 > So I guess what we=E2=80=99d want is something like =E2=80=98tinker = panic 0=E2=80=99. Actually - reviewing the incident logs - I take that back. The issue is = that panic allows a delta in BOTH directions: if (fabs(fp_offset) > clock_panic && clock_panic > 0 && = !allow_panic) { =E2=80=A6 I guess having two types of panic; one which only allows a large = =E2=80=98panic =E2=80=99s the positive direction would give you the best = of both worlds in VM Land. As across the estate - in my experience; upon = the move of a VM - the clock rarely jumps back more than seconds; if = that. And those hypervisor clocks are in those cases all > 10 seconds = off; so bailing is fair game. Dw