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

Darryl Miles darryl-mailinglists at netbauds.net
Mon Aug 25 08:52:20 UTC 2008


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