zec at icir.org
Thu Dec 1 14:16:23 PST 2005
On Thursday 01 December 2005 22:19, Danial Thom wrote:
> I see you haven't done much empirical testing;
> the assumption that "all is well because intel
> has it all figured out" is not a sound one.
> Interrupt moderation is given but at some point
> you hit a wall, and my point is that you hit a
> wall a lot sooner with MP than with UP, because
> you have to get back to the ring, no matter what
> the intervals are, before they wrap. As you
> increase the intervals (and thus decrease the
> ints/second) you'll lose even more packets,
> because there is less space in the ring when the
> interrupt is generated and less time for the cpu
> to get to it.
Gig-E line rate is around 1.44 Mpps max. If you set up the interrupt
coalescing timers to trigger interrupts with max frequency of 15000
int/s (a pretty standard setting), then the maximum number of packets
buffered due to interrupt delaying will never exceed 100. Given that
even the cheapest NICs have 256 RX slots or more, it is evident that
the issue you are raising is non-existent.
> Flow control isn't like XON/OFF where we say "hey
> our buffer is almost full so lets send some flow
> control" at 9600 baud. By the time you're flow
> controlling you've already lost enough packets to
> piss off your customer base.
No, flow control really works, if tresholds are set up properly then
there's no reason for it to fail, i.e. loose packets at all.
> Plus flow
> controlling a big switch will just result in the
> switch dropping the packets instead of you, so
> what have you really gained?
So what's your point? If a system cannot cope with the incoming
traffic, _somewhere_ a certain amount of packets will have to be
dropped. The real issue is how to make a system more efficiently
handle the offered traffic, not to cry about lost packets.
> Packet loss is real, no matter how much you deny
> it. If you don't believe it, then you need a
> better traffic generator.
More information about the Users