[ntp:questions] Time reset
unruh-spam at physics.ubc.ca
Fri Apr 4 16:05:13 UTC 2008
andy.helten at dot21rts.com (Andy Helten) writes:
>David Woolley wrote:
>> Andy Helten wrote:
>>>>> offset never went >128ms). With time steps enabled the drift value
>>>>> settles <90ppm (and again, no step actually occurs).
>> 90ms is a relatively bad static frequency error; a good machine will be
>> around 10ms. That won't help a clean cold start.
>> I didn't check, but did you have the default min and maxpoll values. A
>> high minpoll might make it difficult to get the loop to converge from
>> there without overflows.
>My current problem is that drift settles at 82ppm (what I called <90 in
>previous email) in one run and then 32ppm in another run (with a reboot
>between). This is similar to the problem I had with stepping disabled
>where drift would go from +500ppm in one run and then swing all the way
>to -500ppm in another run (usually with a reboot between). I am not
>going to spend another minute troubleshooting this problem until we get
>an updated linux kernel. I will dig into it more deeply if the new
>kernel exhibits this same drift instability.
That is an incredibly unstable clock. It is hard to imagine that this is a
kernel problem. This is on one of your machines? It is not the server
connected to the IRIG-B is it?
>Our system is considered "real-time" and thus has many constraints on
>it, namely that it will run in an isolated environment with no Internet
>connection. Our setup runs one machine with NTP as a local stratum 1
>server using an IRIG-B time source. On that machine I have minpoll set
No need for internet if you have a local clock.
>to the lowest (16 seconds). I had to do this so that NTP would begin
>serving sync requests in a reasonable amount. Startup time is another
>constraint and we have other boards running as NTP clients that must
>sync with the NTP server before they can finish initialization. I don't
>set maxpoll on the server because I've never caught the server changing
>the polling interval from 16 seconds -- maybe it's a reference clock
>All other boards in the system run as NTP clients and I use "minpoll 5
>maxpoll 9" for them. I'm not 100% sure why I chose those values, but I
>think the idea was to improve NTP reaction time to changes in the
>"synchronization environment". I'm not sure whether those poll settings
>achieve that, but it sounds like you are suggesting a lower minpoll may
>speed convergence in cases of higher drift.
No. He meant if you had minpoll say 8 or 10 it would make settling down
long if the ssytem did not start with a good drift value.
However, even minpoll 5 means one data sample every 4 hours roughly(since
ntp throws away roughly 7/8 of the samples in the clock_filter). That's a slow
convergence. And even minpoll 4, the minimum, is only one sample every 2
More information about the questions