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

David L. Mills mills at udel.edu
Mon Oct 9 22:27:44 UTC 2006


I know why they changed the design and why Linux did, too. It allows 
quick adjustments with large offsets when done manually. From what 
evidence I have, they use an exponential algorithm, which is simple to 
implement. However, the extra pole that algorithm introduces conflicts 
with the NTP PLL. There really should be a way to turn the algorithm on 
and off, but I don't expect much sympathy from the kernelmongers.


Richard B. Gilbert wrote:
> user at domain.invalid wrote:
>> Richard,
>> The overshoot is the result of a misdirected Solaris/Linux design of 
>> the adjtime() system call. The design added a poll to the transfer 
>> function in order to speed the response to a programmed offset. The 
>> result completely torpedoes the PLL transient response and there is 
>> nothing that can be done to correct it in ntpd itself. What you see is 
>> what you get. The problem is most apparent with large initial 
>> frequency offsets, which are guaranteed to result in pinball behavior. 
>> Note the overshoots do not occur in FreeBSD or Tru64, which have a 
>> reasonable design.
>> Dave
> Dave,
> Have you reported this to Sun as a bug?
> It seems to me that they should fix it and, perhaps, create a new 
> function, say, adjtime_fast() that would add the functionality without 
> breaking ntpd.  It might not get you anywhere but he who does not ask 
> does not get!

More information about the questions mailing list