[ntp:questions] ntpd -x option

Richard B. Gilbert rgilbert88 at comcast.net
Fri Mar 13 22:06:11 UTC 2009

Unruh wrote:
> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>> Unruh wrote:
>>> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>>>> 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.
>>> That 700PPM is NOT the hardware drift, it is what ntp wants to use to bring
>>> a seriously off time clock back to being on time. Remember that ntp adjusts
>>> the clock ONLY by altering the drift rate or by stepping. The user does NOT
>>> want to step ever, even at bootup. Thus he must alter the clock rate. But
>>> if the clock is out by 30min say, ntp will try to use a huge drift rate,
>>> much beyond the 500PPM ntp will allow him to use. 
>>>>> 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 
>>>> offset of that magnitude.)
>>> We are talking about startup. He does NOT want to step the clock ever, even
>>> on startup.
>> He can do that if he wants to and if he doesn't care how far off the 
>> clock is.
> Yes, that is apparently what he wants. Why, none of us know. But he is
> running into the problem that ntp wants to alter the clock by more than
> 500PPM, and that ntp, instead of just clamping to 500PPM and correcting
> your 47 min over the next 90000 min (2 months) ntpd just dies and does
> nothing but leave the clock to wend it own useless way. 
>> Most people who use NTP want the time correct to within one second or 
>> better, usually much better.  He will need to be prepared for the day 
>> when power goes off for three days and, when power returns, his clock is 
>> off by 47 minutes.  Will he spend the next twenty-four plus hours 
>> amortizing that offset or will he set (step) the clock.
> "Most people" is not him apparently. 

It's his privilege to play by his own rules.  If he is willing to spend 
several months slewing the clock. . . .

I would be tempted to slew the clock at a rate far beyond 500 PPM if I 
could figure out how.

More information about the questions mailing list