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

Richard B. Gilbert rgilbert88 at comcast.net
Sat Oct 25 23:53:41 UTC 2008

Unruh wrote:
> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>> Unruh wrote:
>>> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>>>> Hal Murray wrote:
>>>>>> It's the poll interval of ntpd.  Ntpq does not poll!  The poll interval 
>>>>>> varies between 2^MINPOLL and 2^MAXPOLL.  You have set MINPOLL=MAXPOLL=4 
>>>>>> giving a poll interval of 2^4 or 16 seconds.  This is usually the 
>>>>>> correct choice for a GPS receiver.
>>>>> Why do you say that?  
>>>> Because the GPS time signal is extremely accurate!
>>>>> Or let me ask it another way, how would you
>>>>> decide what the right polling interval is?
>>>> NTPD uses much longer poll intervals over the internet or even over a 
>>>> local network because of the variable delays introduced by the network. 
>>>>  No two packets are guaranteed the same path between two points unless 
>>>> there IS only one path.  In addition to the variations in travel time 
>>>> due to differing paths, there are also variable queuing delays!
>>> No. The longer poll intervals are mainly about keeping packets off the servers. In
>>> principle it is always better to poll more. (in practice with the ntp
>>> model, this is only partially true-- you want the 8 times the poll interval
>>> to be close tothe Allan minimum if the noise model really is exponential
>>> phase and 1/f drift noise. ( on most modern networks not the greatest
>>> assumption-- day to night temp variations are probably more important for
>>> the frequency noise). 
>> ntp presents a very light load on the servers unless you have some 
>> idiots polling at two second intervals (other than an initial burst at 
>> startup).
>> The longer poll intervals allow ntpd to measure small errors very 
>> accurately.
> If you want good time, use short polls. If you want good frequency, use
> long polls. ntp tries to strike a balance by having the poll interval be

And if you want both good time AND good frequency?  Ideally the system 
should provide both.

> roughly the minimum of the Allan variance. But since it assumes, rathr than
> measures the location of that minimum, it is pretty useless for any real
> life situation. Thus, If you have continuous connectivity to the server,
> short poll intervals will give you the best time ( but not the best
> frequency) If you occasionally loose connectivity for some period, then the
> lack of good freq will hurt you as the time will drift off too fast. 
> Longer poll intervals thus allow you to measure frequency drifts more
> accurately, but if you have continuous connectivity, why do you care if you
> know the drift rate accurately?
> The primary reason for long poll intervals is not to swamp the public
> servers. -- while one packet is not too bad, 10^6 packets pers second
> because of for example a very badly designed router which has your server's
> address hardwired in totally swamps your connction. 
> So, if it is your own server which only you use, poll as often as you wish.
> If it is someone elses, don't.

More information about the questions mailing list