[ntp:questions] Time reset

Unruh 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 mailing list