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

Unruh unruh-spam at physics.ubc.ca
Wed Oct 1 06:51:44 UTC 2008

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


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

Are you using the -g option? What is the poll interval for your gps clock?
(Use 4 whcih I think is the default for gps clocks.)

ntp is NOT designed for rapid convergence, but on a gps clock with poll
interval 4 and -g it sure should be better than hours.

>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

More information about the questions mailing list