[ntp:questions] Time reset

Andy Helten andy.helten at dot21rts.com
Fri Apr 4 13:46:22 UTC 2008


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.

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

Andy




More information about the questions mailing list