[ntp:questions] ntpd -x option

Unruh unruh-spam at physics.ubc.ca
Fri Mar 13 23:36:17 UTC 2009


"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>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.

On Linux you use the tickadj in adjtimex. Ie, you can tell linux that
instead of 10ms between timer ticks there is just 9ms or 9.145ms between
the timer ticks (assuming a 100MHz timer) Ie, there are two ways to adjust
the clock, via the interpolation routine ( the "frequency") and by adjusting
the timer ticks. The latter is far coarser. ntp does not use it (probably
because it is unique to Linux or something). That is one of the ways taht
chrony uses to get its far faster convergence to the "true time". 

Thus you could do it by hand as root. ( use the adjtimex userland program,
or the adjtimex system call) or write a program to do it. Teh key problem
would be that ntp and that program would end up fighting each other. 
Alternatively  you could rewrite ntp to use the adjtimex timer adjustment
as well as the frequency adjustiment and up the max rate of the ntp slew.
You would have to rewrite the clock rate adjustment routines. The software
one really has no limit on the rate adjustment, but the adjtimex (kernel)
does-- the max frequency adjust is 500PPM so you would have to put in the
logic to decide to start using the tick adjust as well to get the higher
slew rates. 




More information about the questions mailing list