[ntp:questions] Negative delay in 4.2.6p2
Dave Hart
hart at ntp.org
Tue Oct 11 19:17:23 UTC 2011
On Tue, Oct 11, 2011 at 09:10, Marco Marongiu <brontolinux at gmail.com> wrote:
> Hi all
>
> Yes, negative delay. We see this on one of our clients (real IPs concealed):
>
>> $ ntpq -c pe -c as
>> remote refid st t when poll reach delay offset jitter
>> ========================================================
>> -10.100.100.142 22.222.222.6 3 m 66 64 376 -3.302 1.517 0.022
>> +10.100.100.141 22.222.222.7 3 m 63 64 376 -6.828 0.083 0.025
>> +10.100.100.161 222.2.22.84 3 m 54 64 376 -7.786 -0.756 0.035
>> *10.100.100.162 22.222.222.3 3 m 50 64 376 0.314 0.609 0.031
>
> It's a multicast client with symmetric authentication, running ntpd
> 4.2.6.p2 on Linux Debian Squeeze. From our munin graphs, this started to
> happen three weeks ago, and all in a sudden.
>
> Is it a bug?
I suspect not, my guess is something changed in the network to reduce
the delay. Assuming you are not using "broadcastdelay" in your
ntp.conf, each multicast client association starts off with a unicast
"volley" which measures the unicast and broadcast round-trip delay and
stores the difference to correct future broadcast/multicast delays for
that association. ntpd must be restarted to go through the dance
again to pick up changes in the network unicast and broadcast latency.
FYI, if you were to use manycastclient instead of multicastclient,
you'd preserve the automatic server discovery while each client would
be using unicast exchanges with the server, where the delay is
determined with each exchange independently, insulating against
network changes.
Cheers,
Dave Hart
More information about the questions
mailing list