Unruh wrote: > [EMAIL PROTECTED] (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 > hrs. > > Hmmm, clearly the more I learn about NTP, the less I know. Andy _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions