Unruh wrote:
> darryl-mailingli
...@netbauds.net (Darryl Miles) writes:
>> I am currently using NTP 4.2.2p1.
Rather old.
>> 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
ntpd manages that flag. The kernel only changes it on a manual time set
or when the estimated error overflows.
> .
>> 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.
Status is preset to just UNSYNC.
>> * Then NTP would be started.
>> * NTP would take a few minutes to obtain PLL lock with multiple time
>> sources.
ntpd obtains PLL lock with a mix of all the good time sources, unless
you force it to use one. It chooses the reference source long before it
has tight PLL lock.
>> * Then select a preferred source as candidate to configure the kernel.
ntpd's source selection doesn't affect what is fed to the kernel.
Unless one specifically inhibits it, that is a mix of all the valid time
sources.
>> * 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. ***
ntpd releases UNSYNC as soon as it starts disciplining the kernel, which
is long before the PLL has stabilised.
> 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).
This part of the kernel was contributed by the NTP project! The UNSYNC
flag is not masked out in the API, so is controlled by ntpd.
> 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.
It might not be optimal, but it does take steps to improve accuracy.
>> * 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 ?
As noted, I think I believe it controls setting of the RTC clock every
11 minutes. It doesn't look like it affects the behaviour of the kernel
discipline. But then you could have looked at the code, the same as I did.
>> 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.
UNSYNC will tell you when you haven't had updates.
>> 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 ?
UNSYNC gets set (2.4 kernel) when you manually set the time or the
estimated error overflows. In your case, the estimated error is at the
end stop. That could be cause or effect, as setting the time manually
also forces the error to maximum.
>> 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.
The kernel discipline is enabled by default, provided that you don't
have configuration parameters that incompatible. If you did have
incompatible parameters, I don't believe you would get a PLL state.
>> 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 :
I'm not sure if that mode is supported in the official code.
>> # 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. )
Being unsynced indicates a problem. The end stop estimated errors also
indicate a problem. If you don't want the 11 minute mode, build a
kernel without it.
