[ntp:questions] Slow convergence of NTP with GPS/PPS

David Woolley david at ex.djwhome.demon.co.uk.invalid
Wed Oct 1 06:54:26 UTC 2008


Richard B. Gilbert wrote:

> 
> I don't recall that +/- 128ms is specified anywhere.  If ntpd gets it's 
> initial time from a hardware reference clock, the time SHOULD be very 
> close.  This will, off course, depend on the latencies in the reference 
> clock's response and the resolution of the time supplied.
> <snip>


This is where it is documented in the source code for 4.2.4p4 
(ntpd/loopfilter.c):

  *      State   < step          > step          Comments
  *      ====================================================
  *      NSET    FREQ            step, FREQ      no ntp.drift
  *
  *      FSET    SYNC            step, SYNC      ntp.drift
  *

NSET is the initial state for a cold start.  FSET is the initial state 
for a warm start (ntp.drift) present.  For a fast start you don't want 
NSET.  Note that FSET goes to fully synchronised on one reading, but 
only steps the time if the offset is greater than the step limit, which 
normally 128ms.

Furthermore, in the branch that is conditioned thus:

         if (fabs(fp_offset) > clock_max && clock_max > 0) {

there is this comment:

                  * In S_FSET state the initial frequency has been set
                  * from the frequency file. Since the time is outside
                  * the step threshold, the clock is stepped immediately,
                  * rather than after the stepout interval. Guys get
                  * nervous if it takes 17 minutes to set the clock for
                  * the first time.
                  *

immediately followed by:

                         step_systime(fp_offset);

There is no step_systime in the else branch.  clock_max is the tinkered 
value of the parameter that defaults to 128ms.




More information about the questions mailing list