netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: Roland Dreier <rolandd@cisco.com>
Cc: netdev@vger.kernel.org, openib-general@openib.org
Subject: Re: Timeline of IPoIB performance
Date: Mon, 10 Oct 2005 13:17:56 -0700	[thread overview]
Message-ID: <434ACC74.3020404@hp.com> (raw)
In-Reply-To: <521x2tgrim.fsf@cisco.com>

Roland Dreier wrote:
>      > 2.6.12-rc5      in-kernel    1     405   <<<<<
>      > 2.6.12-rc4      in-kernel    1     470   <<<<<
> 
> I was optimistic when I saw this, because the changeover to git
> occurred with 2.6.12-rc2, so I thought I could use git bisect to track
> down exactly when the performance regression happened.
> 
> However, I haven't been able to get numbers that are stable enough to
> track this down.  I have two systems, both HP DL145s with dual Opteron
> 875s and two-port mem-free PCI Express HCAs.  I use MSI-X with the
> completion interrupt affinity set to CPU 0, and "taskset 2" to run
> netserver and netperf on CPU 1.
> 
> With default netperf parameters (just "-H otherguy") I get numbers
> between ~490 MB/sec and ~550 MB/sec for 2.6.12-rc4 and 2.6.12-rc5.
> The numbers are quite consistent between reboots, but if I reboot the
> system (even keeping the kernel identical), I see large performance
> changes.  Presumably something is happening like the cache coloring of
> some hot data structures changing semi-randomly depending on the
> timing of various initialations.

Which rev of netperf are you using, and areyou using the "confidence intervals" 
options (-i, -I)?  for a long time, the linux-unique behaviour of returning the 
overhead bytes for SO_[SND|RCV]BUF and them being 2X what one gives in 
setsockopt() gave netperf some trouble - the socket buffer would double in size 
each iteration on a confidence interval run.  Later netperf versions (late 2.3, 
and 2.4.X) have a kludge for this.

Slightly related to that, IIRC, the linux receiver code adjusts the advertised 
window as the connection goes along - how far the receive code opens the window 
may change from run to run - might that have an effect?  If there is a way to 
get the linux receiver to simply advertise the full window from the beginning 
that might help minimize the number of variables.

Are there large changes in service demand along with the large performance changes?

FWIW, on later netperfs the -T option should allow you to specify the CPU on 
which netperf and/or netserver run, although I've had some trouble reliably 
detecting the right sched_setaffinity syntax among the releases.

rick jones

  parent reply	other threads:[~2005-10-10 20:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1128672413.13948.326.camel@localhost>
     [not found] ` <52br20lsei.fsf@cisco.com>
2005-10-08  2:25   ` Timeline of IPoIB performance Matt Leininger
2005-10-10 18:23     ` Roland Dreier
2005-10-10 20:03       ` Michael S. Tsirkin
2005-10-10 21:03         ` Roland Dreier
2005-10-10 20:17       ` Rick Jones [this message]
2005-10-10 20:58         ` Roland Dreier
2005-10-10 21:22           ` Rick Jones
2005-10-10 21:26       ` Grant Grundler
2005-10-10 23:30         ` Grant Grundler
2005-10-11  0:51           ` Andi Kleen
2005-10-10 23:25       ` Matt Leininger
2005-10-10 23:38         ` Roland Dreier
2005-10-10 23:44           ` Matt Leininger
2005-10-10 23:53             ` Roland Dreier
2005-10-11  4:03               ` Roland Dreier
     [not found] <E1EPIxF-0001Cp-00@gondolin.me.apana.org.au>
2005-10-12 16:53 ` Roland Dreier
2005-10-12 18:28   ` Matt Leininger
2005-10-13  1:24     ` Matt Leininger
2005-10-13  1:48       ` Herbert Xu

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=434ACC74.3020404@hp.com \
    --to=rick.jones2@hp.com \
    --cc=netdev@vger.kernel.org \
    --cc=openib-general@openib.org \
    --cc=rolandd@cisco.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).