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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of David L. Mills > Sent: 02 October 2008 20:12 > To: [email protected] > 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: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] > ntp.org]On > >>Behalf Of David McConnell > >>Sent: 30 September 2008 14:04 > >>To: [email protected]; [EMAIL PROTECTED] > >>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 > >>[email protected] > >>https://lists.ntp.org/mailman/listinfo/questions > >> > > _______________________________________________ > questions mailing list > [email protected] > https://lists.ntp.org/mailman/listinfo/questions > _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
