> 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. ----------- e...@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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
