[ntp:questions] Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync
darryl-mailinglists at netbauds.net
Fri Aug 29 09:27:21 UTC 2008
Steve Kostecke wrote:
> On 2008-08-28, Dave Holland <dh3 at sanger.ac.uk> wrote:
>> Darryl Miles <darryl-mailinglists at netbauds.net> wrote:
>>> I guess an offset of 0.0000 is perfect ?
> 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,
>> 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
This still does not explain why kernel info for me is at the endstops:
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,
More information about the questions