On Apr 9, 4:40 pm, [EMAIL PROTECTED] (Andy) wrote: > > Two things: > (1) Try running with time stepping enabled on that system (i.e. don't > use the '-x' flag) to see how well the system keeps time. What kind of > offset do you have after 1 or 2 hours of operation? > (2) Check your drift value when running with time stepping disabled > (also check it with time stepping enabled). You can do this with 'ntpq > -crv' where 'frequency' is the drift value or you can dump the drift > file (probably /var/lib/ntp/drift). Note that the drift file is only > updated once every hour or so. > > I encountered a problem on linux 2.6.18 in which disabling of time > stepping (using either '-x' or 'tinker step 0') caused the drift value > to run at or near +/-500ppm and subsequently caused a time offset of > several milliseconds. If I allow time steps on that same system, it > runs with a drift <100ppm and maintains an offset <1ms. I am using an > IRIG time source, so I expect high accuracy. In my system, a time step > is never needed (i.e. the offset never grows larger than 128ms), > regardless of whether time stepping is enabled or disabled. This > doesn't change the fact that it runs like crap with time stepping disabled. > > Andy
Note that the my set-up was an experiment to check how time slew worked. What I still don't get is why it works when using ntpdate. Also strange is the fact that ntpq actually reports the node as synched with an offset of > 1.6s. Jan _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
