On 06/11/2012 02:29 AM, unruh wrote: -snip- > Anyway, from the very preliminary tests, this seems to have solved the > main problem. Of course that problem that on that one machine about half > the packets have a .14ms return time and the other half have 1.5ms > return time is not solved. From the scatter plot, this delay is occuring > on the return leg of the round trip. Something is delaying them by a ms. > on that return trip. The ethernet card on this machine is that Intel > Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
That figure (1.5ms) makes me recall a patch I did for a machine with an old 82559 rev 8: "Linux: Tweak coalescing in e100 aka Intel Pro/100. i82559(08,09) and possibly also i82551(0F,10) will randomly delay received packets up to 1.5 ms. This patch disables coalescing for packets less than 256 bytes so that NTP traffic will not suffer. " It changes a microcode constant so that ntp-sized packets also bypass coalescing, not just ACK-sized packets. http://wap.taur.dk/patch/e100ntp.patch You may also want (not mine) http://wap.taur.dk/patch/fastarp.patch particularly if the machine is not running tickless. ARP will make it appear as if there is an occasional ~500us delay in the outbound direction. When running non-tickless, there may be an additional one-tick (1ms typical) delay in sending the ARP request. The easy test fot this is to put in a static ARP entry on each end. (assuming you, or a friend, won't mind building your own kernel) /Kasper Pedersen _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions