[ntp:hackers] ntpdate removal is coming

Brian Utterback brian.utterback at oracle.com
Sun Jul 24 03:08:52 UTC 2011

On 07/23/11 20:06, Dave Hart wrote:
> [questions@ removed from cc: by Dave Hart]
> 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.
> Cheers,
> Dave Hart

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


Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.utterback at oracle.com

More information about the hackers mailing list