Date: Thu, 24 Sep 2015 08:23:27 -0600 From: Ian Lepore <ian@freebsd.org> To: Dirk-Willem van Gulik <dirkx@webweaving.org> Cc: Erik Cederstrand <erik+lists@cederstrand.dk>, FreeBSD Hackers <hackers@freebsd.org> Subject: Re: What IS the right NTP behaviour ? Message-ID: <1443104607.1224.265.camel@freebsd.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 Thu, 2015-09-24 at 11:27 +0200, Dirk-Willem van Gulik 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’. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1443104607.1224.265.camel>