[ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
Unruh
unruh-spam at physics.ubc.ca
Fri Feb 13 16:31:10 UTC 2009
Martin Burnicki <martin.burnicki at meinberg.de> writes:
>Danny,
>Danny Mayer wrote:
>> Martin Burnicki wrote:
>>> Of course synchronization will be better if ntpd reaches an upstream
>>> server continuously, but still this is better than no synchronization at
>>> all ...
>>>
>>
>> No it wouldn't. That's a fallacy. ntpd already oversamples. This is all
>> in the algorithms but sampling at the same rate provides no benefit and
>> it is better off reducing the sampling frequency once it has a stable
>> state.
>What I meant is not to decrease the polling interval.
>I meant to apply corrrections to the system time earlier. If you monitor the
>offset in ntpq -p then you can see often it takes very long untio an
>initial offset of a few milliseconds is started to be decreased.
>>> And surely this results in the question which has been discussed here
>>> several times: why does it takes so long for ntpd to adjust an initial
>>> tiny offset of a few milliseconds?
>>>
>>
>> It's easy to overshoot when you have that small of a change.
>The problem is not overshooting, it's just that ntpd applies initial
>corrections very late.
It is not that it applies corrections late. It is just that the algorithm
for applying the corrections-- The use of the offset now to change the
clock rate as the only correction process, with absolutely no memory
retained of prior offsets-- is very slow. It is simple, a simple second
order freedback system, and stable but slow.
More information about the questions
mailing list