[ntp:questions] Time reset
andy.helten at dot21rts.com
Fri Apr 4 16:39:16 UTC 2008
> andy.helten at dot21rts.com (Andy Helten) writes:
>> 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?
I'm fairly certain the board's oscillator is stable. I wrote a simple
perl script that keyed of a PPS print from a GPS-to-IRIGB box. When the
PPS time was printed, I grabbed local system time as well as IRIGB time
from the local IRIGB PMC. Using this approach, the system oscillator's
drift (without NTP running) was measured to be within the +/-30ppm
oscillator specifications. This procedure was reliable over several
runs and was repeated on at least one other board with an IRIG-B receiver.
Yes, there is a potential for problems in many different areas within
this setup, however, after much troubleshooting to isolate the problem,
the 2.6.18 kernel has always been involved in the non-working
configuration. An older kernel worked fine with the same IRIG-B driver,
the same version of NTP, but different hardware, so I haven't completely
exonerated the hardware. At any rate, this has been put on the back
burner until we can get the latest RedHawk release, which isn't due
until mid April.
>> 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
Hmmm, clearly the more I learn about NTP, the less I know.
More information about the questions