[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