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  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
 
 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.