[ntp:questions] Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

Darryl Miles 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 ?
>> 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



More information about the questions mailing list