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

Unruh unruh-spam at physics.ubc.ca
Mon Oct 20 18:35:11 UTC 2008


nb at komeda-berlin.de (Nicola Berndt) writes:

>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

OK, But that should have a convergence of minutes not hours. Mind you NTPs
habit of throwing away 7 out of 8 queries of the clock does not help.
(clock filter). Especially for a pps that is pretty extreme.

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

Hard for it to be on all the time then. Or for it to have anthing like an
accurate time. And that ovenized oscillator will also be pretty useless (
much worse than the GPS) since it will have no power either and the crystal
will not be oscillating nor the oven keeping the temp constant. 


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

So, what you have is a free standing computer which must come out of a cold
shutdown (ie the oscillator frequency on startup will be way off its
frequency in steady state because it is cold) so will be far from
equilibrium. What is your time error requirement? Seconds, milliseconds,
microseconds? In such a situation ntp would probably give you a few
milliseconds. But it certainly is NOT designed to give you good accuracy in
such a situation during startup.  What are you finding?









More information about the questions mailing list