[ntp:hackers] ntpdate removal is coming
hart at ntp.org
Sun Jul 24 03:57:37 UTC 2011
On Sun, Jul 24, 2011 at 03:08 UTC, Brian Utterback
<brian.utterback at oracle.com> wrote:
> On 07/23/11 20:06, Dave Hart wrote:
>> On Sat, Jul 23, 2011 at 23:23 UTC, Brian Utterback
>> <brian.utterback at oracle.com> wrote:
>>> On 07/17/11 15:57, Harlan Stenn wrote:
>>>> If anybody knows of any *good* reasons to set the clock before starting
>>>> ntpd, please speak up.
>>> How about because of bug 1044?
>> Dr. Mills indicated in a comment to 1044 that your description is
>> incorrect, that the initial zero offset is not given to the kernel
>> when a drift file is present. There have been no further comments in
>> the intervening 3 years. If there is a problem with current code,
>> please respond to that assertion with another bug comment.
> The version of NTP I have been working with is a bit out of date. I am
> building the latest to try it out again. Actually, the problem is with
> both 1043 and 1044, they are related.
> The issue is not so much with what ntpd does, but what ntp_adjtime does
> in the kernel. In both bugs we assume that the daemon has not been
> running for long enough to accrue an offset of up to 128ms. When the
> ntp_adjtime call is used to set the offset or the frequency, the
> reference time is reset. So, if the frequency is set at start up in any
> manner, either to 0 or to the value in the drift file, the kernel
> reference time is reset. If immediately after that, the offset is set,
> the kernel takes this offset, divides by the interval between the
> reftime and now to get the drift rate. So, the sooner after the
> frequency setting the offset setting is done, the larger the calculated
> (bogus) frequency becomes. Now, this is a PLL, so the new frequency does
> not just replace the old one, but it does perturb it by what could be a
> very large amount, which the PLL then have to amortize back to what it
> should be.
> This problem is avoided by running ntpdate just before starting ntpd
> because this will guarantee that the offset if small.
> Now, this is arguably a bug in the way the kernel handles the reftime.
> Or maybe not. In any case, it is the way the kernel reference code
> works, or worked, so you pretty much have to assume that the kernel
> suffers from the problem.
> I did not update these bugs because as you can see in the comments to
> 1043, Dr. Mills did not view it as a problem worth solving. I suspect
> that this is because the systems he regularly uses probably do not have
> this problem in the kernel, or maybe he just never lets ntpd stop
> running long enough to accrue a large offset. In any case, my experience
> is that this can present major problems to the PLL and the time to
Thanks for your timely response. I don't read Dr. Mills' comment on
1043 quite as you characterize. I'm hoping he will respond himself to
this thread. However, I want to note that ntpd's startup behavior
changed in the 4.2.7 timeframe, which may change the situation for
both 1043 and 1044. When ntpd starts with a driftfile, any initial
offset less than the step threshold is slewed away over 300 seconds,
_without affecting the frequency_ (at least for the daemon
discipline). Without a driftfile, ntpd now determines the frequency
correction over 300 seconds rather than 1024 seconds as before, then
in the second 300 seconds rapidly slews away any offset, again without
perturbing the frequency correction.
Turning back to the initial topic, removing ntpdate: It seems very
likely to me that either sntp or ntpd -q ("ntpdate mode") could be
used in place of ntpdate, if indeed 1043 and/or 1044 compel you to set
the time before starting the daemon ntpd. So from my perspective,
regardless of the resolution of 1043 and 1044, neither provides reason
to keep ntpdate around.
More information about the hackers