[ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

Unruh unruh-spam at physics.ubc.ca
Thu Jan 24 23:16:21 UTC 2008


"David L. Mills" <mills at udel.edu> writes:

>Unruh,

>The NTP discipline is basically a type-II feedback control system. Your 
>training should recall exactly how such a loop works and how it responds 
>to a 50-ms step. Eleven seconds after NTP comes up the mitigation 
>algorithms present that transient to the loop and what happens 
>afterwards conforms to the equations of control theory. Discussion about 
>what happens at any time after that is a matter of mathematics and ntpd 
>does conform to the mathematics as confirmed by observation and simulation.

Of course it conforms the equations of control theory. That is NOT the
issue. You need to measure the offset and the drift rate and compensate for
them. That is the issue. The question here is now to do that. You use the
immediate offset value to control a feedback loop with a very long time
constant. The question is whether or not using the past 10 or 20, or even
adaptively changing how many of the past values to use in making those
estimates of the drift and of correcting the offset. 


>If you have problems with the loop time constant, tough. It was chosen 
>as a compromise for LANs and WANs. You are invited to justify a 
>different time constant, but it has to work an a bumpy road to Malaysia.

I certainly have trouble with the time constant. It is long. I means that
ntp responds very slowly to changes. I understand why it was chosen. But it
is also true that building the system for a bumpy road to Malaysia requires
a different car than on the streets of New York.

Anyway, the question is not whether or not the design of ntp is reasonable,
it is. The question is whether or not it is "best". On the streets of
Vancouver, it is definitely not "best".





>Further discussion on this issue is neither interesting nor helpful and, 
>frankly, boring.

OK, that is of course up to you. 



>Dave

>Unruh wrote:

>> "David L. Mills" <mills at udel.edu> writes:
>> 
>> 
>>>Maarten,
>> 
>> 
>>>I turn my machines off and on all the time and the clock is set from the 
>>>server within 11 seconds after starting ntpd. If I didn't use burst 
>>>mode, that would take four minutes. Golly.
>> 
>> 
>> When you say "the clock is set" what do you mean? With what accuracy is the
>> clock running 4 min after powerup in comparison with its accuracy after say
>> 5 days. (let me define the accuracy as the offset ,not the jitter, but the
>> offset on each measurement from your best time source.)
>> 
>> 
>> 
>> 
>> 
>>>Please understand the difference between impulse response and poll 
>>>interval. It is true that it might take 3000 s to amortize the initial 
>>>offset from the TOC chip at power-up. This is no different than if some 
>>>server torqued your clock by that amount.
>> 
>> 
>> So, if some server did torque your clock by 50ms as a one time event, or if
>> you stepped your system clock by 50ms, how long would it take ntp to settle
>> down (lets say you are running at maxpoll 7, minpoll 4). Let us assume that
>> in steady state your clock is controlled to 50usec. HOw long would it take
>> to regain that +- 50usec behaviour with ntp? Again, I mean by +- 50 usec
>> that the measurement offsets ( what is reported in the peerstats
>> file as "clock offset") are fluctuating by +-50usec?
>> You may not like that as a measure of the clock accuracy, but I want to be
>> clear that we are not talking about different things.
>> 
>> 
>> 
>> 
>> 
>> 
>>>Dave
>> 
>> 
>>>Maarten Wiltink wrote:
>>>
>>>>"Unruh" <unruh-spam at physics.ubc.ca> wrote in message
>>>>news:aCqlj.12849$vp3.7702 at edtnps90...
>>>>
>>>>
>>>>>"David L. Mills" <mills at udel.edu> writes:
>>>>
>>>>
>>>>>>There are lots of ways to measure the loop transient response. The
>>>>>>easiest way is to set the clock some 50-100 ms off from some stable
>>>>>>source (not necessarily accurate) and watch the loop converge. The
>>>>>>response should cross zero in about 3000 s and overshoot about 6
>>>>>>percent
>>>>>
>>>>>3000 s is a HUGE time. For people who switch on their computers daily,
>>>>>that means most of their time is spent with the computer unsynchronised
>>>>>to best accuracy. The timescale of chrony is far faster. (I am not a
>>>>>writer of chrony.I am a user who is trying to get the very best out of
>>>>>the timekeeping.)
>>>>
>>>>
>>>>But NTP is from a time when people didn't switch on their computers
>>>>daily. When NTP was young, dinosaurs walked the machine room and
>>>>_you_ did _not_ get to decide when the machine on the other end of
>>>>your terminal was rebooted.
>>>>
>>>>NTP can, after weeks of training, teach a computer to keep time very,
>>>>very well. As a result, it's less optimised for the other end of the
>>>>spectrum.
>>>>
>>>>Features like iburst and the drift file can get your clock synchronised
>>>>to within a few milliseconds in less than a minute. If you want better
>>>>than that, or you want it faster... don't turn your computer off.
>>>>
>>>>Groetjes,
>>>>Maarten Wiltink
>>>>
>>>>




More information about the questions mailing list