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

Unruh unruh-spam at physics.ubc.ca
Fri Oct 3 01:33:45 UTC 2008

davidm at pipstechnology.co.uk (David McConnell) writes:

>Thanks for the responses.

>We have tried -g and minpoll/maxpoll are by default 4 for the GPS reference
>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.

That sounds like your drift rate in /etc/drift is way out, or that you do
not have such a file.

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

Yup it could do. This seems to be a problem.

>> -----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
>> Hi
>> 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
>> convergence).
>> 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
>> clock)?
>> 2) If so, how - and what are the tradeoffs?
>> Any help appreciated
>> David
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/questions

More information about the questions mailing list