Steve Kostecke wrote: > On 2008-08-28, Dave Holland <[EMAIL PROTECTED]> wrote: >> Darryl Miles <[EMAIL PROTECTED]> wrote: >> >>> I guess an offset of 0.0000 is perfect ? >> Yes. > > Remember that these stats are just a snapshot. The real indicator of > clock stability is to summarize the stats over a long period of time.
Yes and I still see it that NTP the daemon is in the correct position to make the judgment. All that remains is to feed NTP with a command detailing your bounds/requirements and let it come back with an opinion in respect of that. >>> Now how do I tell the difference between an offset being reported as >>> 0.0000 due to no sync and an offset being reported as 0.0000 due to a >>> perfect sync ? >> Look at the output of that command while (say) NTP is starting up and >> not yet synchronised: >> >> assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart, >> offset=0.000 >> >> compared to normal running: >> >> assID=0 status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg, So "sync_ntp" is the important one here ? And the state of convergence is the current estimated "offset" ? I think what I want it both "sync_ntp" and a small enough offset to be happy. This still does not explain why kernel info for me is at the endstops: ntpdc> kerninfo pll offset: 4294.97 s pll frequency: -62.504 ppm maximum error: 16.384 s estimated error: 16.384 s status: 0041 pll unsync pll time constant: 6 precision: 1e-06 s frequency tolerance: 512 ppm The systems appear to be keeping time but are not happy to reduce their estimate of possible error. Thanks for all your pointers in this matter, Darryl _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
