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

Unruh unruh-spam at physics.ubc.ca
Sun Oct 26 00:13:31 UTC 2008


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

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

There is a tradeoff, and you have to decide where in that tradeoff you want
to be. For most people, when they ask for the time, they want the  minimum
error in that time. for some they want time spans (eg measuring 100 sec
they want the least error in thet 100 s) Some want that if their
connectivity goes down for a day, the time on their machine during that day
is as small as possible. All demand different strategies. And by "good"
what do you mean?

In general in measuring anything the more measurements you have the better
it is. Unfortunately it also depends on how those measurements are used.
ntp uses ONLY the latest measurements to adjust the clock. Old measurements
are thrown away. That is valuable data.




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