NTPsec leap second experience

[Hal Murray]

> I'm somewhat embarrassed to admit that I have understood very little of your
> exposition about this.  I'm a software systems architect, not a metrologist,
> and the stuff going on down at the PLL level is still a bit beyond my ken.

The field is complex.  There are big thick textbooks on it.

Wikipedia has a couple of good articles.

Phase-locked loop
  https://en.wikipedia.org/wiki/Phase-locked_loop

PID controller
  https://en.wikipedia.org/wiki/PID_controller

The usual problem with badly designed/implemented PLLs is that they oscillate.  A less evil problem is overshoot.  You may be willing to trade some overshoot to gain faster response.

The bump option in ntpfrob lets you see what the PLL does in response to an error signal.

The smeared leap second gave us a test case for a step change in the frequency.
  http://users.megapathdsl.net/~hmurray/time-nuts/leap/ntp-goog-leap.png
There is a 50 ms overshoot at the end of the smear.  There is a similar overshoot at the start, but it's harder to see since its hidden by the slope of the line.

-----------


esr at thyrsus.com said:
> However, what I *do* take away is that our drastic reduction surgery on the
> rest of the suite apparently has not accidentally damaged the PLL nor
> screwed up its convergence properties. I find that very reassuring. 

I'm pretty sure that somebody would have noticed if we had really broken something in that area.


-- 
These are my opinions.  I hate spam.