On Tue, Oct 11, 2011 at 09:10, Marco Marongiu <[email protected]> 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
