What IS the right NTP behaviour ?

[Ian Lepore]

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 at cederstrand.dk> wrote:
> > 
> >> Den 23/09/2015 kl. 22.33 skrev dirkx at webweaving.org:
> >> 
> >>> On 23 Sep 2015, at 21:27, Brian Reichert <reichert at 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 at 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