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