[ntp:questions] oscillations in ntp clock synchronization

Rick Jones rick.jones2 at hp.com
Fri Jan 18 19:15:32 UTC 2008

Unruh <unruh-spam at physics.ubc.ca> wrote:
> www.theory.physics.ubc.ca/chrony/chrony.html

Which reads in part:

   This seems to imply that the outbound ntp packets take slightly
   longer than the inbound packets.

Which seems rather strange indeed.  Typically, an application calls
"send" and it goes down the stack to be queued to the NIC.  If there
is nothing else queued to the NIC, the NIC is to be told "Hey! There
be traffic here!" and the NIC should DMA it from the host and transmit
it onto the network. Now, the NIC might not generate a transmit
completion interrupt right away... but the packet should be on its
way.  Although...  if there _is_ traffic already queued to the NIC,
this packet will be taked to the end of the list and the "end index"
is supposed to be updated so the NIC knows to keep going.  I suppose
if the NIC didn't grab that index again until after a transmit
completion interrupt, and transmit completion interrupts were
delayed... or I suppose just good old fashioned queuing delay could be
involved if there is other traffic...

On the other hand, recv might easily take longer - at least for GbE
NICs and their drivers the drivers often set the interrupt settings to
favor bulk throughput over low latency and a packet can arrive at the
NIC, be DMA'd into the host, and the NIC _not_ tell the host right
away, but wait for a while until either a timer on the NIC expires or
more traffic arrives.  This shows-up as poor netperf TCP_RR behaviour
on a number of NICs and their drivers.

rick jones
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

More information about the questions mailing list