All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nivedita Singhvi <niv@us.ibm.com>
To: Diwaker Gupta <diwakergupta@gmail.com>
Cc: xen-devel@lists.sourceforge.net
Subject: Re: I/O descriptor ring size bottleneck?
Date: Mon, 21 Mar 2005 15:42:41 -0800	[thread overview]
Message-ID: <423F5BF1.3000502@us.ibm.com> (raw)
In-Reply-To: <1b0b4557050320134748a984df@mail.gmail.com>

Diwaker Gupta wrote:

> Hi everyone,
> 
> I'm doing some networking experiments over high BDP topologies. Right
> now the configuration is quite simple -- two Xen boxes connected via a
> dummynet router. The dummynet router is set to limit bandwidth to
> 500Mbps and simulate an RTT of 80ms.
> 
> I'm using the following sysctl values:
> net.ipv4.tcp_rmem = 4096        87380   4194304
> net.ipv4.tcp_wmem = 4096        65536   4194304

If you're trying to tune TCP traffic, then you might
want to increase the default TCP socket size (87380) above
as well, as simply increasing the core size won't
help there.

> Now if I run 50 netperf flows lasting 80 seconds (1000RTTs) from
> inside  a VM on one box talking to the netserver on the VM on the
> other box, I get a per flow throughput of around ~2.5Mbps (which
> sucks, but lets ignore the absolute value for the moment).
> 
> If I run the same test, but this time from inside dom0, I get a per
> flow throughput of around 6Mbps.

Could you get any further information on your test/data?
Which netperf test were you running, btw?

> I'm trying to understand the difference in performance. It seems to me
> that the I/O descriptor ring sizes are hard coded to 256 -- could that
> be a bottleneck here? If not, have people experience similar problems?

Someone on this list had posted that they would be getting
oprofile working soon - you might want to retry your testing
with that patch.

thanks,
Nivedita



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

  reply	other threads:[~2005-03-21 23:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-20 21:47 I/O descriptor ring size bottleneck? Diwaker Gupta
2005-03-21 23:42 ` Nivedita Singhvi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-03-20 22:15 Ian Pratt
2005-03-21  0:06 ` Diwaker Gupta
2005-03-21  0:36 Ian Pratt

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=423F5BF1.3000502@us.ibm.com \
    --to=niv@us.ibm.com \
    --cc=diwakergupta@gmail.com \
    --cc=xen-devel@lists.sourceforge.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.