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

David L. Mills mills at udel.edu
Tue Aug 26 21:00:38 UTC 2008


Darryl,

It doesn't make sense to manage that bit. Use the maximum error 
statistic instead.

When the client is first started until setting the clock, this statistic 
will be large (~16 s), as it is in your example. Once the clock is set 
and after that this statistic is set to the synchronization distance 
determined by the daemon.

If the daemon crashes or loses all sources, the kernel will increase the 
distance as required by the specification. Application programs can 
establish their own bound (~1 s) above which they consider the clock 
unsynchronized. The problem with managing the bit is that the kernel 
doesn't know your particular bound.

Dave

Darryl Miles wrote:
> I am currently using NTP 4.2.2p1.
> 
> My problem is with the management of the "unsync" flag in the kernel.  
> This is visible from the "status" line in :
> 
> ntpdc> kerninfo
> pll offset:           4.7e-05 s
> pll frequency:        -62.146 ppm
> maximum error:        16.384 s
> estimated error:      16.384 s
> status:               0041  pll unsync
> pll time constant:    2
> precision:            1e-06 s
> frequency tolerance:  512 ppm
> ntpdc>
> 
> 
> Older version of NTP used to manage this flag, this is my understanding 
> of how things used worked (based on observation not understanding) :
> 
>  * Kernel would bootup and by default the status would have the "unsync" 
> bit set.
>  * Then NTP would be started.
>  * NTP would take a few minutes to obtain PLL lock with multiple time 
> sources.
>  * Then select a preferred source as candidate to configure the kernel.
>  * NTP would then configure the kernel PLL to obtain convergence.
>  *** Once convergence was complete the 0x40 UNSYNC bitwise flag would be 
> reset in the kernel by NTP. ***
>  * NTP would continue to monitor/manage/update the kernel PLL.
> 
> It appears since between version 4.2.0.a.20040617 and 4.2.2p1 the 
> penultimate item in the list above is no longer occurring.
> 
> 
> 
> Question 1) Can someone confirm is the "UNSYNC" status flag held inside 
> the kernel is arbitrary, i.e. its just an informational flag and is 
> independent of the operation / function of NTP ?
> 
> 
> Question 2) Am I correctly interpreting the purpose of the UNSYNC flag 
> ?  I have a periodic script that runs and checks to see if adjtimex 
> reports the nominal status of 0x01 PLL, as opposed to (anything else for 
> example 0x41 = PLL|UNSYNC).   This used to provide me with a mechanism 
> to alert me to problems with NTP configuration when a host became UNSYNC 
> so that as administrator I could investigate why a system became unsync.
> 
> 
> Question 3) If NTP exits/crashes does the kernel automatically re-arm 
> the UNSYNC flag if the PLL data has not been updated within a specified 
> period of time (like within 3 minutes) ?  i.e. the kernel will fail-safe 
> back to UNSYNC if it can clearly observe that no application has called 
> the appropiate NTP API to keep the UNSYNC status flag muted.  This is a 
> sort of watchdog that does the correct thing in the case of failure ?
> 
> 
> When I googled this problem I found a suggestion that "enable kernel" 
> command can do the trick.  I do use NTP keys between my external data 
> sources and when I tried this command into ntpdc it asked me for a key.
> 
> ntpdc> enable kernel
> Keyid: 1
> MD5 Password:
> ***Permission denied
> ntpdc>
> 
> 
> Both systems run ntp as non-root, both systems have the appropriate Linux kernel capability bit set CAP_SYS_TIME : 
> 
> # cat /proc/3268/status
> CapInh: 0000000002000000
> CapPrm: 0000000002000000
> CapEff: 0000000002000000
> 
> I guess in order to configure the PLL ntp is going to need that capability anyway.
> 
> 
> 
> So I'm at a bit for a loss as what the cause of the UNSYNC flag sticking 
> long after both NTP and the kernel have obtain a good enough PLL sync to 
> believe they are "in-step".
> 
> 
> Thanks,
> 
> Darryl




More information about the questions mailing list