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

David L. Mills mills at udel.edu
Tue Oct 17 16:38:42 UTC 2006


In the semi-linear scenario you describe, and with the default poll 
interval of 64 s, the response crosses zero in about 3000 s. The zero 
crossing is directly dependent on the poll interval, but the overshoot 
is not. Setting the poll interval to 16 s results in a zero crossing of 
about 750 s. It can't be set less than that because the adjustment 
interval is fixed at 1 s. With the kernel code the poll interval can in 
principle be set less than 16 s, but that extreme is really not a good idea.

Setting the step threshold less than the default has no effect other 
than the state machine, but would make the Lamporter among use real 
squirrely. Most squirrels want to set it higher.

I'm not sure what the agenda here has become, but I think just about 
anything that can be said about it has been said.


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.
> It looks to me that the only way that he is going to get fast convergence
> under these conditions is by tinkering the step limit to 1ms or less
> (better: several standard deviations larger than the expected phase
> noise).  However tinkering is discouraged and sometimes causes other
> features to be turned off.
> His other option, I suppose, is to deliberately set the clock wrongly
> so that it is guaranteed to be out by more than 128ms.
> Basically, you only get the good performance documented in the PDF file
> if the initial error is either negligible, or is quite large.
>>Your scenario where the operator slings the frequency as the response 
>>crosses zero is equivalent to a frequency-lock model which disregards 
>>the initial phase error. This is in fact the model for the initial 
>>frequency estimate when the frequency file has not yet been created. 
> That is a transition from zero frequency correction to the estimated
> required correction.  The scenario I was considering was a transition from
> a maximum (positive or negative) correction to the nominal value.
> By the way, looking at the state diagram in that PDF file, I can only make
> sense of it if I assume that the arcs from SYNC for events 1 and 2 have 
> had their labels mixed up.

More information about the questions mailing list