[ntp:questions] Re: ntpd PLL and clock overshoot

Richard B. Gilbert rgilbert88 at comcast.net
Tue Oct 17 00:44:35 UTC 2006


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