From: Rick Jones < rick.jones2@hp.com>
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP vs RADclock?
unruh wrote:
> Tried that. Makes no difference to scatter of return time on the
> client. Do not know if that means that interrupt coalescence is
> still on, or that it makes not difference. The problem appears to be
> in the receipt of the packets, not the transmission (although I
> guess it could still coalesce interrupts on receipt as well.)

Avoiding TX completion interrupts started happening with 100BT NICs.
Schemes like only taking a TX completion interrupt when it covered more
than half the transmit queue, and then checking TX completions on RX
interrupts. Coalescing RX completion interrupts arrived with GbE
NICs. If you have all the values as zeros, then presumably there
should be a 1-1 between interrupts and packets sent/received.
Presumably then there should be a 1-1 between packets sent/received
(ifconfig or ethtool -S) and counters incrementing in /proc/interrupts
for the IRQ(s) of the interface.

-------------------------------------------

From: Rick Jones < rick.jones2@hp.com>
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP vs RADclock?

unruh wrote:

> OK, Since I set the rx-usecs: 0 the clients have lost that strong
> correlation of return trip to offset that they had. Ie, it does
> appear that there was interrupt coalescence going on in the receipt
> of the packets on my Gb Ethernet card, and it was adding randomly up
> to about 50us to the return trip ( and increasing the to the
> uncertainty of the clock measured offsets to about 10 us) Thus, if
> your server has a Gb Ethernet card, make sure it is actually running
> at Gb speed, and that the rx-usecs is 0.

The GbE NICs of other vendors will have different semantics for
rx-usecs == 3. In the case of e1000 (PCI-X and some PCIe cards
depending on era) (and probably e1000e - PCIe cards) driven NICs from
Intel a value of three means it was doing a dynamic interrupt
throttle/coalescing heuristic. Broadcom or other vendor NICs will
have different semantics, though indeed if all the -usecs and -frames
are set to zero it should disable interrupt coalescing in the
NIC. (Though best to triple check with the vendor documentation)

In the case of Intel GbE NICs, I think once one gets above a value of
'8' then one is setting an actual coalescing timer.

The effect of disabling interrupt coalescing on other aspects of
performance besides NTP is left as an exercise to the reader(s). One
increasingly old example can be seen, for the time being at least, at

ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt