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

Unruh unruh-spam at physics.ubc.ca
Sat Oct 25 15:19:04 UTC 2008

"David J Taylor" <david-taylor at blueyonder.neither-this-part.nor-this-bit.co.uk> writes:

>David Woolley wrote:
>> David J Taylor wrote:
>>>   "Our application requires good time accuracy (better than 5ms) but
>>> it also needs to get there quickly (as quickly as possible, but
>>> ideally taking no more than about 15 minutes)."
>>> I would have thought that a GPS and NTP would have been able to
>>> achieve that, at least with a current drift file.
>> Assuming default parameters and worst case initial error, and no PPS,
>> it will start with an error of 128ms and take about 40 minutes before
>> it crosses zero.  It will then overshoot, so, might take several
>> cycles to settle within 5ms.  Using minpoll 4 may get it to cross
>> zero within the 15 minutes, but the overshoot may still violate the
>> criteria.

>OK, David, so having a GPS/PPS source and distributing that to the clients 
>should be far better?  How much better?

That is his minpoll 4 case. refclocks are almost always run at minpoll 4.
They could be run at minpoll 2 but ntp will not allow it. 

>Isn't the 128ms a worst-case estimate, because NTP would set the time by 
>stepping initially if the appropriate parameter is specified?  Wouldn't 
>the initial offset then be near zero?

That was what he said "worst case initial error" He should have said
127.999msec though I think:-)

Actually it is NOT the worst case scenario. Try  a drift which is seriously
off instead. That takes much longer to settle down. First ntp has to notice
that the drift is off, and then has to start correcting it. Thus a drift of
say 200PPM (500 would be a worst case, but ntp cannot correct a 500PPM
drift so there is no point in going there) will take quite a bit longer to
correct (should take about twice as long to first go through zero).


More information about the questions mailing list