netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: jamal <hadi@cyberus.ca>
Cc: Chris Friesen <cfriesen@nortelnetworks.com>,
	Cacophonix <cacophonix@yahoo.com>,
	linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: bonding vs 802.3ad/Cisco EtherChannel link agregation
Date: Tue, 17 Sep 2002 09:43:21 -0700	[thread overview]
Message-ID: <3D875BA9.70501@candelatech.com> (raw)
In-Reply-To: Pine.GSO.4.30.0209170608510.1371-100000@shell.cyberus.ca

jamal wrote:
> 
> On Mon, 16 Sep 2002, Ben Greear wrote:
> 
> 
>>Also, I notice lots of out-of-order packets on a single gigE link when running at high
>>speeds (SMP machine), so the kernel is still having to reorder quite a few packets.
>>Has anyone done any tests to see how much worse it is with dual-port bonding?
> 
> 
> It will depend on the scheduling algorithm used.
> Always remember that reordering is BAD for TCP and you shall be fine.
> Typical for TCP you want to run a single flow onto a single NIC.
> If you are running some UDP type control app in a cluster environment
> where ordering is a non-issue then you could maximize throughput
> by sending as fast as you can on all interfaces.
> 
> 
>>NAPI helps my problem, but does not make it go away entirely.
>>
> 
> 
> Could you be more specific as to where you see reordering with NAPI?
> Please dont disappear. What us it that you see that makes you believe
> theres reordering with NAPI i.edescribe your test setup etc.

I have a program that sends and receives UDP packets with 32-bit sequence
numbers.  I can detect OOO packets if they fit into the last 10 packets
received.  If they are farther out of order than that, the code treats
them as dropped....

I used smp_afinity to tie a NIC to a CPU, and the napi patch for 2.4.20-pre7.

When sending and receiving 250Mbps of UDP/IP traffic (sending over cross-over
cable to other NIC on same machine), I see the occasional OOO packet.  I also
see bogus dropped packets, which means sometimes the order is off by 10 or more
packets....

The other fun thing about this setup is that after running around 65 billion bytes
with this test,
the machine crashes with an OOPs.  I can repeat this at will, but so far only on
this dual-proc machine, and only using the e1000 driver (NAPI or regular).  Soon, I'll
test with a 4-port tulip NIC to see if I can take the e1000 out of the equation...

I can also repeat the at slower speeds (50Mbps send & recieve), and using
the pktgen tool.  If anyone else is running high sustained SEND & RECEIVE traffic,
I would be interested to know their stability!

I have had a single-proc machine running the exact same (SMP) kernel as the dual-proc
machine, but using the tulip driver, and it has run solid for 2 days, sending &
receiving over 1.3 trillion bytes :)

Thanks,
Ben




> 
> cheers,
> jamal
> 


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

  reply	other threads:[~2002-09-17 16:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-12 18:39 bonding vs 802.3ad/Cisco EtherChannel link agregation Boris Protopopov
2002-09-12 23:34 ` David S. Miller
2002-09-13 14:29   ` Chris Friesen
2002-09-13 22:22     ` Cacophonix
2002-09-16 13:23       ` Chris Friesen
2002-09-16 16:09         ` Ben Greear
2002-09-16 19:55           ` David S. Miller
2002-09-16 21:10             ` Chris Friesen
2002-09-16 21:04               ` David S. Miller
2002-09-16 21:22                 ` Chris Friesen
2002-09-16 21:17                   ` David S. Miller
2002-09-17 10:16           ` jamal
2002-09-17 16:43             ` Ben Greear [this message]
2002-09-18  1:07               ` jamal
2002-09-18  4:06                 ` Ben Greear
2002-09-18 11:48                   ` jamal
  -- strict thread matches above, loose matches on Subject: below --
2002-09-13  1:30 Feldman, Scott
2002-09-13 14:50 ` Boris Protopopov
2002-09-16 20:12 Yan-Fa Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D875BA9.70501@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=cacophonix@yahoo.com \
    --cc=cfriesen@nortelnetworks.com \
    --cc=hadi@cyberus.ca \
    --cc=linux-net@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).