[ntp:questions] Time reset

Richard B. Gilbert rgilbert88 at comcast.net
Fri Apr 4 17:09:45 UTC 2008


Unruh wrote:
> 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
>>feature.
> 
> 
>>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
> hrs.
> 
> 

I must be missing something!  Minpoll=5 means 2^5 seconds is the minimum 
poll interval.  How are you getting to every four hours from that?  ISTR 
that the default minpoll is 6 which gives 2^6 or 64 seconds.

If the server lines in ntp.conf include the "iburst" keyword, the 
servers will be polled with an initial burst of eight requests sent at 
two second intervals.  This fills the pipeline and "pacifies" the 
filter.  Thereafter, ntpd adjusts the polling interval as it thinks 
best.  Normally the poll interval will increase to somewhere between 256 
and 1024 seconds once the clock is synchronized.  In general, the better 
the network connection the higher the maximum poll interval.

It's interesting to watch the performance of ntpd improve as the network 
quiets down during the hours when most people sleep!





More information about the questions mailing list