[ntp:questions] NTP vs RADclock?

unruh unruh at invalid.ca
Mon Jun 11 20:22:29 UTC 2012


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 <ntp at taur.dk> 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



More information about the questions mailing list