# [ntp:questions] ntpdate function

unruh unruh at invalid.ca
Thu Apr 18 16:02:58 UTC 2013

```On 2013-04-18, Jacek Igalson <jacek.igalson> wrote:
>
> Uzytkownik "unruh" <unruh at invalid.ca> napisal w wiadomosci
>> On 2013-04-15, Jacek Igalson <jacek.igalson> wrote:
>>> In fact, I have used offset,
>>> delay is recorded by the way.
>>> It indicates how asymmetric might be the trip.
>>
>> No. It says nothing about the asymmetry. Just about the delay. Now you
>> might make the assumption that a longer delay is probably a delay in
>> only one leg of the path, implying asymmetry (which is what ntpd does in
>> its clock filter algorithm) and that might often be a reasonable
>> assumption, expecially if the delay is is say twice as long as usual, it
>> is often a very bad assumption for slightly longer delays.
>>
>
> Upper limit of the asymmetry is delay. At least we know that value.

Yes. And the upper limit on your age is 1000 years, but would you say
that is a good estimate? And furthermore, that does not give you the
sign of the asymmetry.
If the delay is significantly longer than the "average" then it is
probably that that extra delay is due to asymmetry. And the offset will
tell you the sign of that asymmetry. See for example the graphs of the
offset vs delay on www.theory.physics.ubc.ca/chrony/chrony.html
There is a huge symmetric clustering around the average delay, with arms
reaching out from there due to asymmetric delays.

ntpd is designed to throw away all of the last 8 measurements except for
the one with the minimal delay. statistically that is a really
profligate use of data. As can be seen from the graphs, most of the
delays are random, and the variation "averages out". Thus getting a
factor of 3 smaller variation would seem to be advantageous over using
simply the shortest delay. (even if that is only shorter by 1%)
Also this treatment of the data is one of the reasons why ntpd is so
slow to respond to changes in the rate of the clock. The procedure would
be good if the clock rate fluctuations were far smaller than the delay
induced variations, but on modern systems on ethernet this is in general
not true. The rate fluctuations due to temp changes in the computer are
relatively large compared to the fluctuations in the measured rate due
to network delays, and ntpd handles them poorly.

Of course if the delay gets large, then the probability is that it is
due to asymmetry.

Eg, ntpd'c clock filter algorithm could probably profitably be replaced
with one in which only those events whose delay is say twice the minimum
are thrown out. This should give ntpd a faster response rate (but
clearly tests with real data should be used to tune that factor).

chrony has an adjustable parameter as to which measurements to throw
out (eg twice the minimum, 1.5,...).

>
>

```