[ntp:questions] Re: ntpd Not Converging

David L. Mills mills at udel.edu
Sat Nov 5 02:00:48 UTC 2005


If you are using the kernel discipline, be advised it is not designed to 
handle offsets greater than 0.5 s. Your question about the control law 
is answered in the briefings on the NTP project page. Technically, the 
control law is a hybrid, adaptive-parameter, phase/frequency feedback 
loop, which of course doesn't tell you much. Control theorists would 
recognize it as a somewhat modified second-order phase-locked loop.

Folks who can't stand to be jerked should first mumble ntptime -f 0. 
Then remove the ntp.drift file and put disable kernel in the 
configuration file.


ntptime -f 0

David T. Ashley wrote:

> Thanks to everyone who responded.  I do appreciate all of the good advice 
> about not using Stratum 1 servers during development, etc.
> But the replies did not zero in on the key question.  It is a control law 
> question.  When ntpd starts and the server time is off of the true time by 
> an offset (say, 2 seconds), what "control law" does it apply to reconverge 
> the server's time and the true time?
> Again, when I start ntpd with /var/lib/ntp/drift not present, it always 
> works.  I've noticed that ntpd waits about an hour and 15 minutes to use the 
> time difference to adjust the "frequency" of the kernel timing parameters to 
> go towards convergence.  It is only when the drift file exists that it 
> doesn't seem to try to converge the server's time and the true time.
> I've adjusted my startup to always delete /var/lib/ntp/drift, and this works 
> fine.  But I'd like to understand the control law involved.
> By "control law" I mean the discrete time transfer function that influences 
> the stability and long-term convergence characteristics of the system.
> I appreciate all of the replies.  But none of them seem centered on the core 
> issue, which is the control law.
> Thanks, Dave. 

More information about the questions mailing list