On Tue, Jul 24, 2001 at 12:07:15PM -0400, Michael Khusid wrote:
> I am new on this mailing list, so please bear with me :)
Sure :)
> I was volunteered to study the performance of some ethernet NICs. So, I set
> up a bridge and that gets me plenty of opportunities to excercise the NICs.
> I am wondering whether the performance limits I observe are caused by the
> bridging code, by the NICs themselves or by something else.
I can pretty much rule out the bridge code. All it does is look something
up in a table and send the packet out again (much like routing). NIC drivers
can be important.
> Machine specs: PIII-1000GHz, Serverworks chipset, various NICs used, Redhat
> 7.1 with 2.4.6 bridging kernel.
>
> (Side comment: it took me only 2-3 hours to set up a linux box, download new
> kernel and compile it with bridging support. It worked flawlessly. Thanks to
> everyone, esp. Lennert, for making it happen!)
Doesn't Red Hat 7.1 come with bridging enabled by default?
> Now, to the main topic. I have observed very different performance if the
> box runs in unidirectional or bidirectional bridging. That is, if I generate
> traffic to eth0 and bridge it into eth1, I can achieve up to 60 to 65Mbps
> throughput. At higher input traffic rates, the box starts dropping packets,
> but the 60 or so Mbps still gets through.
With which cards have you observed this?
> However, if traffic runs in both directions, I am limited to 15Mbps (each
> direction). At higher rates, even 20Mbps in each directions, I see
> unrepeatable behavior. For example, sometimes bridge stops forwarding in one
> direction completely (i.e. 100% loss from eth0 to eth1 and 0% loss from eth1
> to eth0), and sometimes it forwards with 30% loss in both directions. Why is
> the bridge behavior unrepeatable? Why is bidirectional bridging much slower
> than unidirectioanl bridging?
These are good questions. Questions I don't really have an answer to. There
is something you can try though. Do you have a tulip-based card? If so, can
you try with the driver available at the following URL? It reportedly does
200000 pps no problem by switching to polling instead of interrupt-driven
mode under high loads.
ftp://robur.slu.se/pub/Linux/net-development/tulip-ss010402-poll.tar.gz
If this driver does give you the full 100Mbps, I think we have something
to blame: the currently dominant interrupt-driven packet receive processing
path.
> I generate traffic with Smartbits traffic generator using 60 byte packets.
This is a piece of hardware rather than software?
cheers,
Lennert
--
I are sigfile disease!!
All your quote are belong to us.
Copy us every "sig"!
_______________________________________________
Bridge mailing list
[EMAIL PROTECTED]
http://www.math.leidenuniv.nl/mailman/listinfo/bridge
