Re: iperf reported throughput

Excerpts from Usman S. Ansari's message of Sun Nov 28 12:36:44 -0600 2010:
> 
> Appreciate if someone can shed light on this.
> 
> I am running iperf on two systems connected via 10 GB cards. I am seeing lot of
> difference between through put reported by server and client.
> 
> Iperf threads     Through put report Gb/s
>                  (by server) / (by client)
>       3                 8.68 / 8.68 <=== same ===
>       4                 8.61 / 9.47 <=== different ===
> 
> In past I have seen differences in through put reported by server and client,
> but not by this much.
> 
> Can someone tell why this is so and which number to trust ?

When asking for help like this, please be sure to include the versions of
Iperf used during a test as well as brief summary of the OS and hardware that
is used on each host.  The actual Iperf output is usually helpful as well.  

Is this a TCP or a UDP test?  

For a TCP test I'd expect them to be pretty close.  If those numbers are from
a TCP test I'd like to hear more about your setup.  Sometimes they are off a
little bit due to the fact that the interval of time used to calculate the
throughput might vary a bit on client and server. 

Sometimes the UDP numbers vary a bit because with UDP it's just blasting
packets out without any flow control.  In this case the server number is the

Re: iperf ignoring -w(TCP window size flag)

Excerpts from martin's message of Mon Nov 15 05:30:11 -0600 2010:
> Me and a friend of mine troubleshooted one issue with TCP throughput
> and used "TCP window size flag" option of Iperf. The problem was, that
> Iperf often ignored this flag. For example like this:
> 
> TCP window size:  16 KByte (WARNING: requested  150 KByte)
> 
> However, I tested now between a FreeBSD, Ubuntu and Suse machine using
> Iperf versions 2.0.4 and 2.0.5 and now it seemed to be working. Have
> you encountered any issues with "TCP window size flag"? Should TCP
> window size be configured only at client side or server side as well?
> 
> thanks you in advance!
> 

This looks like the OS had a limit on how large of a window you could request.
This isn't a bug with Iperf but an OS imposed limit.  For information on how
to raise this limit.

http://fasterdata.es.net/TCP-tuning/background.html

There are links on that page for details on tuning TCP on a variety of
operating systems.

Jon
--

-- 
Jon M. Dugan <jdugan@...>
ESnet Network Engineering Group
Lawrence Berkeley National Laboratory

Re: iperf reported throughput

On Tue, 30 Nov 2010, Jon Dugan wrote:
> Excerpts from Usman S. Ansari's message of Sun Nov 28 12:36:44 -0600 2010:
> > I am running iperf on two systems connected via 10 GB cards. I am seeing lot of
> > difference between through put reported by server and client.

> For a TCP test I'd expect them to be pretty close.  If those numbers are from
> a TCP test I'd like to hear more about your setup.  Sometimes they are off a
> little bit due to the fact that the interval of time used to calculate the
> throughput might vary a bit on client and server. 

I suggested in private correspondence to increase the duration of the 
test and this made values converge. So I guess your guess might be 
right.

For short tests could OS buffers also skew results? Or has iperf some 
kind of acknowledgement protocol to avoid this?

> Sometimes the UDP numbers vary a bit because with UDP it's just blasting
> packets out without any flow control.  In this case the server number is the
> accurate number since it will be what it was able to receive.  That will at
> least be a lower bound.  It turns out that UDP reception can be difficult even
> for fairly beefy hosts so sometimes the packets are lost a receive time.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________

Re: [Bulk] Re: iperf reported throughput

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev

_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Bulk] Re: iperf reported throughput

2010/12/1 Usman S. Ansari <uansari@...>:
>
> Marc, I am not sure what you mean by OS buffers.

When a send() system call returns the data has typically not been sent
yet but just been buffered for sending.

In case the iperf sender stops the stopwatch immediately after the
last send() call has returned then the throughput computation is too
optimistic, especially for short duration tests. But maybe iperf knows
better?

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

iperf-2.0.5 UDP issues

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d

_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users