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

Unruh unruh-spam at physics.ubc.ca
Wed Oct 1 07:11:30 UTC 2008


"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>David Woolley wrote:
>> Richard B. Gilbert wrote:
>> 
>>>
>>> If you are using a recent version of ntpd, start it with the "-g" 
>>> switch.  That will cause it to set the clock to the correct time once 
>>> only!  If you have a good drift file, you should be synchronized in 
>>> thirty seconds or so and be within ten milliseconds, or less, of the 
>>> correct time.
>> 
>> My understanding was that -g turns off the 1000 second check for the 
>> first step, but still leaves the time within +/- 128ms, which will still 
>> take an unacceptable time to converge to +/- 5ms.  Certainly the 4.2.4p4 
>> documentation makes no claims for it beyond once only disabling the 1000 
>> second check.

>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>

ntp steps if the time is out by more than 128ms. If it is out by more than
1000 seconds it aborts. -g stops that abort once, presumably at intial
startup. Thus if at initial startup th etime is out by >128ms, it will step
the time ( to the correct time) and if the drift file is right, will then
run with that correct drift and the correct time. If it is out by <128ms it
will adjust the frequency to try to reduce that offset via the feedback
loop. Since the max rate is 500PPM if it is out by 128ms it will take min 4
min to adjust, but likely much longer. The max adjust depends on the poll
interval. Now for the refclocks I know, that is 4 (16s) so the time
constants in that feedback loop are about 4 min. if I recall correctly.
 (It is such that it is longer than the max time between data which is 
via the filter algorithm is one data point per 8 poll intervals. 
That is the time to reduce the error by about 1/e so it will take about 5
of those intervals or 20min. (Yes, I know it is not a simple exponential
falloff).
This is a design decision. And David will defend this "slow convergence"
"to the death". chrony is much faster, but does not do refclocks at all so
that is a useless option here. 






More information about the questions mailing list