netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Tvrtko A. Ursulin" <tvrtko@ursulin.net>
To: Chris Snook <csnook@redhat.com>
Cc: netdev@vger.kernel.org
Subject: Re: Bonding gigabit and fast?
Date: Tue, 16 Dec 2008 20:12:29 +0000	[thread overview]
Message-ID: <200812162012.29811.tvrtko@ursulin.net> (raw)
In-Reply-To: <49480775.4060408@redhat.com>

On Tuesday 16 December 2008 19:54:29 Chris Snook wrote:
> > When serving data from the machine I get 13.7 MB/s aggregated while with
> > a single slave (so bond still active) I get 5.6 MB/s for gigabit and 9.1
> > MB/s for fast. Yes, that's not a typo - fast ethernet is faster than
> > gigabit.
>
> That would qualify as something very wrong with your gigabit card.  What do
> you get when bonding is completely disabled?

With same testing methology (ie. serving from Samba to CIFS) it averages to 
around 10 Mb/s, so somewhat faster than when bonded but still terribly 
unstable. Problem is I think it was much better under older kernels. I wrote 
about it before:

http://lkml.org/lkml/2008/11/20/418
http://bugzilla.kernel.org/show_bug.cgi?id=6796

Stephen thinks it may be limited PCI bandwith, but the fact that I get double 
speed in the opposite direction and that slow direction was previously 
roughly double of what it is now, makes me suspicious that there is a 
regression here somewhere.

> > That is actually another problem I was trying to get to the bottom of for
> > some time. Gigabit adapter is skge in a PCI slot and outgoing bandwith
> > oscillates a lot during transfer, much more than on 8139too which is both
> > stable and faster.
>
> The gigabit card might be sharing a PCI bus with your disk controller, so
> swapping which slots the cards are in might make gigabit work faster, but
> it sounds more like the driver is doing something stupid with interrupt
> servicing.

Dang you are right, they really do share the same interrupt. And I have 
nowhere else to move that card since it is a single PCI slot. Interestingly, 
fast ethernet (eth0) generates double number of interrupts than gigabit 
(eth1) and SATA combined.

>From powertop:

Top causes for wakeups:
  65.5% (11091.1)       <interrupt> : eth0
  32.9% (5570.5)       <interrupt> : sata_sil, eth1

Tvrtko

  reply	other threads:[~2008-12-16 20:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-16 19:39 Bonding gigabit and fast? Tvrtko A. Ursulin
2008-12-16 19:54 ` Chris Snook
2008-12-16 20:12   ` Tvrtko A. Ursulin [this message]
2008-12-16 20:37     ` Chris Snook
2008-12-16 22:55       ` Tvrtko A. Ursulin
2008-12-17  4:48         ` Jay Vosburgh
2008-12-17  7:51           ` Tvrtko A. Ursulin
2008-12-17  7:37         ` Tvrtko A. Ursulin
2008-12-17 20:18       ` skge performance sensitivity (WAS: Bonding gigabit and fast?) Tvrtko A. Ursulin
2008-12-17  2:53 ` Bonding gigabit and fast? Trent Piepho
2008-12-17  7:51   ` Tvrtko A. Ursulin

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=200812162012.29811.tvrtko@ursulin.net \
    --to=tvrtko@ursulin.net \
    --cc=csnook@redhat.com \
    --cc=netdev@vger.kernel.org \
    /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).