Unruh <[EMAIL PROTECTED]> 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... _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions