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

Unruh unruh-spam at physics.ubc.ca
Tue Aug 26 19:22:57 UTC 2008

darryl-mailinglists at netbauds.net (Darryl Miles) writes:

>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 :

The kernel manages that flag. It has problems, for example the 11 min
write-to-rtc which can mess up any attempt to maintain rtc statistics and
drift. Ie it is better to have it off

>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

>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 
> * 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 has nothing to do with the kernel. The kernel is Linus Torvald's
business, not David Mills (much to that latter's annoyance when the kernel
people mess up the kernel timekeeping).

As far as I know, the only purpose of that flag is turn on the 11 min rtc
procedure ( evey 11 min the kernel resets the rtc to the current system
time) with a very inaccurate procedure.

> * 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.

A far better idea is to monitor the offset from the ntp servers to let you
know if there is a clock problem.

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

I do not think so. 

>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

>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".

Leave it unsynced. It serves no useful purpose AFAIK. hwclock is a much better
idea to use to set the rtc, and does a much better job of it ( including
determining the drift of the rtc and compensating for it. )



More information about the questions mailing list