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

Nicola Berndt nb at komeda-berlin.de
Mon Oct 20 17:33:13 UTC 2008


Unruh schrieb:
>> I understand that ntp is not designed for wild and fast changes, but to 
>> my understanding these are not always necessary, given pretty well 
>> defined startup-conditions like a reboot. Well, when I reboot my VIA 
>> epia 12000EG I experience right the phenomenon David described: ntpd 
>> sets the time pretty fast initially using the -g switch but then 
>> increases the offset a lot, turns around, shoots over 0 again and after 
>> a long time finally reaches a very high precision. This happens with and 
>> without a driftfile.
>>     
>
> Your frequency is off. But for a PPS signal you should set the poll
> interval to the lowest possible 4. 
> The convergence time is related to the poll interval. 
> Anyway, what your behaviour indicates is that your system is starting with
> the wrong notion of what the correct frequency is, and is hunting around to
> find it. This is the fault of the ntp memoryless algorithm, since the first
> three readings of the clock should give it a pretty good notion of what the
> clock rate is. But ntp does not use that information in an efficient manner
> at all. 
>
>   
I see, that's too bad then.. :( I am already using minpoll 4 maxpoll 4
>   
>> My plan was (well, IS - I just ordered it today..) to get a Soekris net 
>> 4501 and maybe even an ovenized oscilator on an external board, since we 
>> have some tasks that simply depend on very precise time.
>>     
>
> ??? This just means that that system is on all the time. Just leave your
> pps attached computer on all the time and it will deliver times with an
> accuracy of a few microseconds. Why you would want to pay for that
> expensive device I do not know, unless you really need sub-microsecond
> resolution. But then any of the clients will not get that anyway. Network
> delays give you 10's of usec fluctuations. 
>
>
>   
No, the Soekris will run linux an d ntpd and the oscillator will just be 
on an external little board. The computer is residing in an airport 
hangar for MONTH sometimes with no powersource at all! There is 
absolutely no way to leavi it on, especially since it is a part of the 
airplane, wich has to be cut of even it's battery when unattended for a 
longer period.
>> The option to just use an application that simply reads NMEA and PPS is 
>> of no use for me anymore (I had that plan in the very beginning), since 
>> we have to sync several devices to the GPS/PPS equipped unit.
>>     
>
> Why not? Just sync several devices to that GPS/PPS equipped unit. Go ahead.
>
>
>   
Yes, one could do that, right. I must think about it. It takes away 
quite some freedom, though, meaning a bunch more cables that have to be 
attached to every unit OR writing something like gps that can sync to 
another computer. I am no programmer so I guess I will try hard not to 
do that.
>> So my question actually is: Is this initial variance part of the plan or 
>> do I have a chance to get around it with the Soekris board?
>>     
>
> That board will do you absolutely no good at all if you then use it as the
> time source for your server, unless you need ns long term resolution. NTP's
> design, which David Mills strenuously sticks to,  has the design feature
> that it is slow to converge. It is not necessary, but it was his design
> decision. Chrony made a different design decision and converges far far
> faster. Unfortunately, it works only on Linux and does not have any ability
> to read atomic clocks (like PPS). But it is certainly proof of concept that
> fast convergence is possible while disciplining the  computer clock to a
> higher degree of accuracy than does ntp.
>
>
>   
Well, all in all rather bad news for me. I must sit down and think of a 
good way out...

Thx for the hints and regards,
../nico



More information about the questions mailing list