Date: Thu, 24 Sep 2015 11:32:28 +0200 From: Dirk-Willem van Gulik <dirkx@webweaving.org> To: Erik Cederstrand <erik+lists@cederstrand.dk> Cc: FreeBSD Hackers <hackers@freebsd.org> Subject: Re: What IS the right NTP behaviour ? Message-ID: <2E0C3E03-127C-4765-B359-7809B4B057F0@webweaving.org> In-Reply-To: <05581AEE-5A92-49B0-8F35-FE96BE15CF2A@webweaving.org> References: <39337.1442999127@critter.freebsd.dk> <F6AF299A-17B1-44DF-B025-B8FA0BC833D4@kientzle.com> <CAJm4238%2BJCfg7Xb2vMJ4--4uLPXrjn6EJzuc8xJdAeA-aXr7-A@mail.gmail.com> <20150923192729.GB78209@numachi.com> <D5902190-FC96-427B-A8DE-89E66500E145@webweaving.org> <0CAEE340-B9DF-4772-8600-8A0904636452@cederstrand.dk> <05581AEE-5A92-49B0-8F35-FE96BE15CF2A@webweaving.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 24 Sep 2015, at 11:27, Dirk-Willem van Gulik <dirkx@webweaving.org> = wrote: >=20 > On 24 Sep 2015, at 11:12, Erik Cederstrand <erik+lists@cederstrand.dk> = wrote: >>=20 >>> Den 23/09/2015 kl. 22.33 skrev dirkx@webweaving.org: >>>=20 >>>> On 23 Sep 2015, at 21:27, Brian Reichert <reichert@numachi.com> = 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 <tim@kientzle.com> = 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 = <big-kernel-re-awake-only> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2E0C3E03-127C-4765-B359-7809B4B057F0>