[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: [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
