[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