Yes, negative delay in ntpd. Packets travelling back in time when going from the server to your client. Fasten your seat belts people, Captain Kirk is back 😉
OK, seriously now. As you can expect, I was quite surprised to see this, but it appears to be expected in certain conditions.
Here's the full story. …One day I ran ntpq -c pe -c as on one of our clients, and I found out that the delay was negative for three out of fours servers (real IPs concealed):
$ ntpq -c pe -c as remote refid st t when poll reach delay offset jitter ============================================================================== -10.100.100.142 18.104.22.168 3 m 66 64 376 -3.302 1.517 0.022 +10.100.100.141 22.214.171.124 3 m 63 64 376 -6.828 0.083 0.025 +10.100.100.161 126.96.36.199 3 m 54 64 376 -7.786 -0.756 0.035 *10.100.100.162 188.8.131.52 3 m 50 64 376 0.314 0.609 0.031 ind assid status conf reach auth condition last_event cnt =========================================================== 1 61991 731a no yes ok outlyer sys_peer 1 2 61992 741a no yes ok candidate sys_peer 1 3 61993 741a no yes ok candidate sys_peer 1 4 61994 761a no yes ok sys.peer sys_peer 1
As you can imagine, I was a lot surprised… how could it be?
I posted my question to the relevant list, asking if it was a bug.
I got some contrasting answers. Some think I actually hit a bug. Others are less sure. But the bottom line seems clear: it is… well, "normal", it could happen in a multicast setting.
We'll wait and see if 4.2.8 fixes it.
2 thoughts on “NTP packets travelling back in time?”
Maybe! But I think that this could be a better explanation: http://tinyurl.com/5ubvqfy
that may explain why some neutrinos were FTL at CERN! 🙂