[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
>> file.
>> 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 mailing list