[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