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

David McConnell davidm at pipstechnology.co.uk
Fri Oct 3 17:49:43 UTC 2008


Based on the replies, we have (regretfully) decided that ntpd does not suit
our particular need.

Instead we have written some software to read GPS sentences + handle PPS
pulse interrupts and manage the system time ourselves.
Somewhat crude, but seems to work OK so far....

Thanks again for all the help.

David


> -----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 L. Mills
> Sent: 02 October 2008 20:12
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>
>
> David,
>
> 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.
>
> Dave
>
> 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
> >>
> >>
> >>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
> >>
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
>





More information about the questions mailing list