[ntp:questions] Re: ntpd PLL and clock overshoot

David Woolley david at djwhome.demon.co.uk
Sat Oct 14 21:21:49 UTC 2006


In article <9tCdnQXAi99MsKzYnZ2dnUVZ_vKdnZ2d at comcast.com>,
Richard B. Gilbert <rgilbert88 at comcast.net> wrote:

> I believe that Dave Mills has already explained that the problem is due 
>   to changes in the adjtime() routine in both Sun Solaris and Unix. 

No.  He has explained that the 100% overshoot problem is due to that.  We
are talking about a 10% overshoot here.  Dave Mills has said that a 6 to 7%
overshoot represents the intended normal behaviour and that a 10% overshoot
could well be the result of approximations to that in the actual implementation.

(This is on a subthread about 10% overshoots, but something produced a 
one entry References line, so it is possible that the threading is broken.)

> b. Get Sun and the Linux developers to back out the change to adjtime() 
> that broke ntpd.

Have they violated their own documentation?  If not they have no
reason to do so.

> c. Provide a custom adjtime() for each platform affected.  I suspect 

That's more or less done anyway.

> that the routine in question runs in kernel mode and may be part of the 
> kernel so that this may be easier said than done!

>From what I understand from what Dave Mills said recently about reasons
for not using large minimum step values, the problem only happens when
adjtime is used, i.e. the kernel time discipline is disabled or not used,
so the ntpd code involved is in user space.  (Also, the API for the kernel
code is not adjtime, but adjtimex, ntpadjtime, etc.)




More information about the questions mailing list