What is interesting is that there are two identical machines, with the same kernel (2.6.24.7-desktop-3mnb) and the same ethernet card, as reported by lspci, and one suffers from that binary problem of half of the ntp packets suffering a 1.05ms delay, while the other machine does not have that problem. Also, the delay is exactly 1.03 ms. Ie there is not a distribution of values, just two packets with exactly the same distribution but displaced by that value. That does not really sound like interrupt coalescence to me, but I may just not understand it.
On 2012-06-11, Kasper Pedersen <[email protected]> wrote: > > 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 [email protected] http://lists.ntp.org/listinfo/questions
