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>
index | next in thread | previous in thread | raw e-mail
> On 24 Sep 2015, at 11:27, Dirk-Willem van Gulik <dirkx@webweaving.org> wrote: > > On 24 Sep 2015, at 11:12, Erik Cederstrand <erik+lists@cederstrand.dk> wrote: >> >>> Den 23/09/2015 kl. 22.33 skrev dirkx@webweaving.org: >>> >>>> On 23 Sep 2015, at 21:27, Brian Reichert <reichert@numachi.com> 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 <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). >>>>> >>>>> 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 <big-kernel-re-awake-only> panic 0’. 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) { … I guess having two types of panic; one which only allows a large ‘panic ’s 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. Dwhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2E0C3E03-127C-4765-B359-7809B4B057F0>