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

Unruh unruh-spam at physics.ubc.ca
Mon Oct 20 15:46:23 UTC 2008

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


>just found this thread, after having not studied the list for quite a 
>while. I have the exact same problem (have to be ready within minutes) 
>and I also have an accurate (and meanwhile excellently working) PPS signal.

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

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

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

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


>Best regards,
>./nico berndt

More information about the questions mailing list