DP performance

[Danial Thom]

--- Marko Zec <zec at xxxxxxxx> wrote:

> 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.

no box in existence can handle 1.44Mpps, so why
are  you arguing a case that can't possibly be
made? 

> 
> > 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.

Intel boxes don't send out flow control unless
the bus has been saturated (ie doing gigE on a
32bit bus) or until the ring has been breached.
In both cases its too late as you've lost 100s of
packets.

Flow control is not an issue here anyway; its a
stupid point. The goal is to be able to handle
the traffic without flow control. Its like saying
that it doesn't matter how fast memory is because
programs will wait. Its just plain stupid.


> 
> > 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.

The "point" is that if you are receiving some #
of packets, it means that the device before you
can handle it and you can't. It means that you
are the bottleneck, and you don't belong in the
path. It means that your device is unsuitable to
be used as a networking device on such a network.
Thats all it means.


DT



		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs