[ntp:questions] Re: ntpd PLL and clock overshoot
David L. Mills
mills at udel.edu
Tue Oct 17 16:57:30 UTC 2006
You say the initial offset starts out at +90 ms and then "overshoots to
-9 ms". It can't do that; the PLL/FLL impulse response with default poll
interval crosses zero in about 3000 s, then <overshoots> about 6
percent. Even if you set the poll interval to the minimum 16 s, the zero
crossing would be about 750 s with identical overshoot.
What you describe looks like the clock is being set directly, not
disciplined by the PLL/FLL loop, or the adjtime() system call is broken,
as discussed previously. The discipline loop acts as a lowpass filter;
it cannot torque the offset "quickly" as you describe.
I do assume your ntpd code is relatively recent, like in the last year
or two. While some details of the ntpd initial training states have
changed in minor ways, the semi-linear PLL/FLL loop has been unchanged
for some time. The old xntpd code was seriously broken in this area and
displayed ntpq data that could be in serious error.
Richard B. Gilbert wrote:
> David Woolley wrote:
>> In article <egr25e$kd3$1 at scrotar.nss.udel.edu>,
>> David L. Mills <mills at udel.edu> wrote:
>>> You are victim of faulty engineering intuition. See Chapter 4 in The
>>> Book. See the graphs therein showing the response to initial
>> Don't have easy access to the book, but looking at the PDF version
>> of NTP Clock Discipline Principles, dated 2004-08-24, the case we are
>> discussing here starts in state FSET, gets a type 0 event and
>> goes to TSET, with no side effects, then gets another type 0 event and
>> transitions to state SYNC, resetting the stepout timer and starting
>> to feed the semi-linear part of the control loop. It does this because
>> the initial error is only 90ms and because there is an ntp.drift
>> That effectively short circuits the state machine logic after only one
>> sample, so the start up behaviour is completely dominated by the PLL/FLL.
>> The person reporting the symptom knows he is using an accurate radio
>> clock and probably believes that the true phase noise is 100 microseconds
>> or less, but actually sees the phase take significant time to reach zero
>> error and then proceed to overshoot to 9ms in the other direction.
> I have seen EXACTLY this behavior with ntpd and my Motorola Oncore. Ntpd
> started up with a 90 millisecond positive offset, overshot to minus
> nine milliseconds. . . . It took about thirty minutes get really
> tight synchronization. Solaris 8.
More information about the questions