On 2011-11-30, Pete Ashdown <[email protected]> wrote: > David Woolley <[email protected]> writes: > >>Richard B. Gilbert wrote: >>> On 11/29/2011 1:42 PM, Pete Ashdown wrote: > >>>> +time-C.timefreq .ACTS. 1 u 19 64 377 37.887 >>>> -16011. 0.122 > >>>> Is there anything I can do to decrease the convergence time? >>> >>> Little or nothing! NTPD can, and sometimes does, take ten hours to >>> reach "steady state". It needs about thirty minutes to find a > >>16 second excursions are not the result of ntpd convergence delays. >>They indicate something seriously broken. Possibly something else is >>trying to set the time. > > Thanks for the pointer David. I added the local hardware clock (127.127.1.0) > to the ntp.conf and that nailed it down. Now my convergence is under a > minute!
One problem in the sequence you showed was that your oncore gps started off 1 second out from "true time". It then seems to have corrected itself. This may well have confused ntpd into starting a huge drift correction, which then played itself out. I do not understand why the 128ms rule did not get applied. Certainly having a refclock be inconsistant to the 1 second level would not do good things for ntpd. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
