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