[EMAIL PROTECTED] (David McConnell) writes: >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. 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: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >> Behalf Of David McConnell >> Sent: 30 September 2008 14:04 >> To: questions@lists.ntp.org; [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 >> questions@lists.ntp.org >> https://lists.ntp.org/mailman/listinfo/questions >> _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions