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

David L. Mills mills at udel.edu
Thu Oct 2 19:11:53 UTC 2008


Your mission is seriously in jeopardy.

The NTP discipline loop has hard constraints on maximum sample rate 
(minimum poll interval) and loop dynamics. If you force the sample rate 
greater than one in 8 s, you violate the loop delay requirement and the 
loop WILL become unstable. There is no magic tinker that does what you 
want. The allan intercept tinker depends on the individual oscillator 
characteristics, not what you want it to do. See the briefings on the 
NPT project page.

You can redesign the loop for faster convergence, but that requires 
changing the seconds timer, which is a major overhaul of the timer 
facility. The loop constants in ntp_loopfilter.c would have to scale in 
the proper mathematical ratio. The equations are in my book. You will 
find the exponential term in the impulse responce equation will be your 
worst enemy.

Your "pretty much perfect" makes sense only if you have the same initial 
conditions, especially the frequency. If you just change the offset, the 
loop dynamics will induce a transient as you observed. The only true 
test is to let the daemon settle, then stop are restart it. It should be 
well within 5 ms for most modern systems.

It appears what you need to conform to a specifcation within a given 
offset within a given time. The NTP discipline can do that just fine as 
long as the initial conditions for the feedback loop are precisely 
known. If you change the offset outside the loop, you must recompute the 
frequency. However, when started for the first time or after a long 
period of absence, the loop has to relearn these conditions and that 
takes time. You can reduce this time be redesigning the loop, but then 
the loop becomes increasingly vulnerable to frequency instability.

 From your description I seriously doubt NTP in its present form is 
appropriate for your application.


David McConnell wrote:
> Thanks for the responses.
> We have tried -g and minpoll/maxpoll are by default 4 for the GPS reference
> clock.
> We even recompiled ntpd with source modified to allow poll at 2sec intervals
> (minpoll=1) but this did not seem to make much difference.
> We have also tried fiddling some of the "tinker" settings (step and stepout)
> but this just seems to lead to instability.
> Also, even if we set the time pretty much perfect (within 5ms offset), ntpd
> appears to first *increase* the offset to well out of our spec, then correct
> through zero offset - overshooting the other way (again well out of our
> spec) and then typically crawls back in after which it is stable - and
> ultimately wonderfully accurate and stable.
> I was hoping that some of the other tinker parameters ("allan" or
> "dispersion" for e.g.) might have an effect - but what are sensible values
> to use?
> I realise that this will compromise ntpd's performance in other ways, but,
> we could tolerate worse final accuracey and jitter in exchange for getting
> to within 5ms "quickly".
> The driftfile also sometimes seems to do more harm than good - especially
> after a reboot.
>>-----Original Message-----
>>From: questions-bounces+davidm=pipstechnology.co.uk at lists.ntp.org
>>[mailto:questions-bounces+davidm=pipstechnology.co.uk at lists.ntp.org]On
>>Behalf Of David McConnell
>>Sent: 30 September 2008 14:04
>>To: questions at lists.ntp.org; linuxpps at ml.enneenne.com
>>Subject: [ntp:questions] Slow convergence of NTP with GPS/PPS
>>We are using Linux ntpd with GPS/PPS reference clock to
>>discipline the time
>>on our systems.
>>Our application requires good time accuracy (better than 5ms)
>>but it also
>>needs to get there quickly (as quickly as possible, but
>>ideally taking no
>>more than about 15 minutes).
>>(The Linux/ntpd is running on a remote embedded device that
>>is frequently
>>restarted - possibly once a day or so - so we cant wait hours for
>>Currently ntpd can take hours to achieve the desired acuracy.
>>So, the question is simple - is there any way to
>>significantly speedup the
>>convergence of ntpd (using GPS/PPS reference clock)?
>>We would be prepared to compromise somewhat on accuracy and jitter.
>>(Currently accuracy and jitter values are excellent with
>>jitter as low as 1
>>microsecond and accuracy better than 10 uS but it can take a
>>day or two to
>>get there).
>>It does not seem unreasonable to expect that the ntpd could
>>achieve the
>>required accuracy within 15 minutes or so - but nothing we
>>have tried seems
>>to work.
>>Have tried modifying some of the tinker values, but we dont really
>>understand what they all do - and have not really had any success.
>>So to summarise:
>>1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
>>2) If so, how - and what are the tradeoffs?
>>Any help appreciated
>>questions mailing list
>>questions at lists.ntp.org

More information about the questions mailing list