[ntp:questions] ntpd -x option

Richard B. Gilbert rgilbert88 at comcast.net
Fri Mar 13 00:50:51 UTC 2009


Unruh wrote:
> Steve Kostecke <kostecke at ntp.org> writes:
> 
>> On 2009-03-12, Unruh <unruh-spam at physics.ubc.ca> wrote:
> 
>>> Ie, IF you do not want to have jumps even on bootup, want fast convergence
>>> to the good time,
> 
>> In your haste to proselytize for chrony you've overlooked the fact the
>> the OP did not specify that he needs fast convergence.
> 
>> In fact, in a discussion on IRC he told me that the speed of convergence
>> is at the bottom of his list of requirements. The most important thing
>> is that his clock _never_ steps.
> 
>>> even if it starts out way off, and want hardware clocks, you have zero
>>> choices at present. You have to give up one of those. Which is the
>>> cheapest to give up?
> 
>> The problem that the OP needs to solve is the fact that ntpd sees that a
>> frequency correction of ~700PPM is required and that it exits.
> 

A frequency correction of 700PPM is outside the limits of the worst that 
  ntpd can handle.  It's indicative of seriously broken hardware.  A 
typical system would need a correction in the range +/- 100 PPM; MOST 
hardware is well within +/- 50 PPM.

> Yes, that will happen with a large correction needed. The correction is
> applied by taking the size of the offset, multiplying it by a small factor
> and altering the rate by the result. If the offset is large, the rate
> change will be large. Now, I had thought that ntp 4.2.4 clamped it at 500PPM but
> my memory of reading the source is not good enough.
> 
Your memory agrees with mine!  500 PPM is the maximum slew rate.

> Note than an offset of minutes or hours  would take many days to correct.
> (At 500PPM, 1 min takes 2000 min to correct, and 1 hour, 2000 hours.
> Why you would want to have your clock out of commission for that length of
> time I do not know. It would almost certainly crash long before it got on
> time, and everything would have to start over. Ie, everyone wants speed. )
> 

An offset of "hours" should never occur.  If it does occur it is, again, 
indicative of seriously broken hardware or human tampering!  (I'm 
assuming that we are not talking about startup with an uncorrected 
offest of that magnitude.)




More information about the questions mailing list