On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
I saw this too, on a system that is "modern" but not terribly fast, and
only slightly (2-way) smp. (the spidernet)
I experimented wih various solutions, none were terribly exciting. The
thing that killed all of them was a crazy test case that someone sprung on
me: They had written a worst-case network ping-pong app: send one
packet, wait for reply, send one packet, etc.
If I waited (indefinitely) for a second packet to show up, the test case
completely stalled (since no second packet would ever arrive). And if I
introduced a timer to wait for a second packet, then I just increased
the latency in the response to the first packet, and this was noticed,
and folks complained.
In the end, I just let it be, and let the system work as a busy-beaver,
with the high interrupt rate. Is this a wise thing to do? I was
thinking that, if the system is under heavy load, then the interrupt
rate would fall, since (for less pathological network loads) more
packets would queue up before the poll was serviced. But I did not
actually measure the interrupt rate under heavy load ...
--linas
-
