netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: hadi@cyberus.ca
Cc: Krishna Kumar2 <krkumar2@in.ibm.com>,
	Gagan Arneja <gaagaan@gmail.com>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	netdev@vger.kernel.org, Sridhar Samudrala <sri@us.ibm.com>,
	David Miller <davem@davemloft.net>,
	Robert Olsson <Robert.Olsson@data.slu.se>
Subject: Re: [WIP][PATCHES] Network xmit batching
Date: Fri, 08 Jun 2007 10:27:46 -0700	[thread overview]
Message-ID: <46699192.6010404@hp.com> (raw)
In-Reply-To: <1181218576.4064.40.camel@localhost>

>>These results are based on the test script that I sent earlier today. I
>>removed the results for UDP 32 procs 512 and 4096 buffer cases since
>>the BW was coming >line speed (infact it was showing 1500Mb/s and
>>4900Mb/s respectively for both the ORG and these bits). 
> 
> 
> I expect UDP to overwhelm the receiver. So the receiver needs a lot more
> tuning (like increased rcv socket buffer sizes to keep up, IMO).
> 
> But yes, the above is an odd result - Rick any insight into this?

Indeed, there is no flow control provided by netperf for the UDP_STREAM 
test and so it is quite common for a receiver to be overwhelmed.  One 
can tweak the SO_RCVBUF size a bit to try to help with transients, but 
if the sender is sustainably faster than the receiver, you have to 
configure netperf with --enable-intervals  and then provide a send burst 
(number of sends) size and an inter burst interval (constrained by "HZ" 
on the platform) to pace the netperf UDP sender.  You can get finer 
grained control with --enable-spin, but that shoots your netperf-sided 
CPU util to hell.

And with UDP datagram sizes > MTU there is (in the abstract, not sure 
about current Linux code) the concern about filling a transmit queue 
with some but not all of the fragments of a datagram and the others 
being tossed, so one ends-up sending unreassemblable datagram fragments.


>>Summary : Average BW (whatever meaning that has) improved 0.65%, while
>>                 Service Demand deteriorated 11.86%
> 
> 
> Sorry, been many moons since i last played with netperf; what does "service
> demand" mean?

Service demand is a measure of efficiency.  It is a 
normalization/reconciliation of the "throughput" and the CPU utilization 
to arrive at a CPU consumed per unit of work figure.  Lower is better.

Now, when running aggregate tests with netperf2 using the "launch a 
bunch in the background with confidence intervals enble to get 
iterations to minimize skew error" :)

<http://www.netperf.org/svn/netperf2/tags/netperf-2.4.3/doc/netperf.html#Using-Netperf-to-Measure-Aggregate-Performance>

you cannot take the netperf service demand directly - each netperf is 
calculating assuming that it is the only thing running on the system. 
It then ass-u-me-s that the CPU util it measured was all for its work. 
This means the service demand figure will be quite higher than it really is.

So, for aggregate tests using netperf2, one has to calculate service 
demand by hand.  Sum the throughput as KB/s, convert the CPU util and 
number of CPUs to a microseconds of CPU consumed per second and divide 
to get microseconds per KB for the aggregate.

rick jones

  parent reply	other threads:[~2007-06-08 17:27 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06 13:49 [WIP][PATCHES] Network xmit batching jamal
2007-06-07  6:16 ` Krishna Kumar2
2007-06-07 11:43   ` jamal
2007-06-07 16:13     ` Evgeniy Polyakov
2007-06-07 22:23       ` jamal
2007-06-08  8:38         ` Evgeniy Polyakov
2007-06-08 11:31           ` jamal
2007-06-08 12:09             ` Evgeniy Polyakov
2007-06-08 13:07               ` jamal
2007-06-08 21:02                 ` Evgeniy Polyakov
2007-06-08  5:05       ` Krishna Kumar2
2007-06-19 13:21     ` Evgeniy Polyakov
2007-06-19 13:33       ` Evgeniy Polyakov
2007-06-19 14:00         ` Evgeniy Polyakov
2007-06-19 14:09           ` Evgeniy Polyakov
2007-06-19 16:32             ` jamal
2007-06-19 16:44               ` Evgeniy Polyakov
2007-06-19 16:28           ` jamal
2007-06-19 16:35             ` Evgeniy Polyakov
2007-06-19 16:45             ` Evgeniy Polyakov
2007-06-19 17:35             ` Robert Olsson
2007-06-19 17:48               ` jamal
2007-06-19 17:55                 ` Evgeniy Polyakov
2007-06-28  0:05                 ` [WIP][PATCHES] Network xmit batching - tg3 support jamal
2007-07-02 21:20                   ` Matt Carlson
2007-07-03  0:21                     ` Michael Chan
2007-07-03 13:26                       ` jamal
2007-07-04  4:19                         ` Krishna Kumar2
2007-07-04 13:22                           ` jamal
2007-07-03 13:09                     ` jamal
2007-07-03 19:31                       ` Matt Carlson
2007-07-04  1:59                         ` jamal
2007-07-03 21:30                       ` David Miller
2007-06-19 22:28               ` [WIP][PATCHES] Network xmit batching David Miller
2007-06-21 15:54                 ` FSCKED clock sources WAS(Re: " jamal
2007-06-21 16:08                   ` jamal
2007-06-21 16:55                     ` Benjamin LaHaise
2007-06-25 16:59                       ` jamal
2007-06-25 17:08                         ` Benjamin LaHaise
2007-06-25 17:16                           ` jamal
2007-06-21 16:45                   ` Evgeniy Polyakov
2007-06-25 16:58                     ` jamal
2007-06-19 16:24       ` jamal
2007-06-21 21:00       ` Rick Jones
2007-06-22  9:59         ` Evgeniy Polyakov
2007-06-25 17:35           ` Rick Jones
2007-06-07  8:42 ` Krishna Kumar2
2007-06-07 12:16   ` jamal
2007-06-08  5:06     ` Krishna Kumar2
2007-06-08 11:14       ` jamal
2007-06-08 11:31         ` Krishna Kumar2
2007-06-08 11:43           ` jamal
2007-06-08 18:00           ` Rick Jones
2007-06-08 17:27     ` Rick Jones [this message]
2007-06-09  0:17       ` jamal
2007-06-09  0:40         ` Rick Jones
2007-06-07 22:42 ` jamal

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=46699192.6010404@hp.com \
    --to=rick.jones2@hp.com \
    --cc=Robert.Olsson@data.slu.se \
    --cc=davem@davemloft.net \
    --cc=gaagaan@gmail.com \
    --cc=hadi@cyberus.ca \
    --cc=johnpol@2ka.mipt.ru \
    --cc=krkumar2@in.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=sri@us.ibm.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).