Jon Dugan | 1 Dec 03:23 2010
Picon

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
(Continue reading)

Jon Dugan | 1 Dec 03:30 2010
Picon

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

(Continue reading)

Marc Herbert | 1 Dec 10:45 2010
Picon

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
_______________________________________________
(Continue reading)

Usman S. Ansari | 1 Dec 18:13 2010
Picon

Re: [Bulk] Re: iperf reported throughput

Marc's suggestion did help me. I increased test time from 10 seconds (default) to 90 seconds. It seems to get more consistent with 30+ second test time. I guess difference is more, because with 10 GB link, more data is being transferred (calculation error is higher).

For completeness sake, both ends are running Scientific Linux version 5.5. Reasonably power machines with PCI-e gen 2 interface.

Marc, I am not sure what you mean by OS buffers. I know that TCP offloads and even NIC cards coalesce data and send in bigger chucks to get more efficient PCI / PCI-e transfers.

On Wed, Dec 1, 2010 at 1:45 AM, Marc Herbert <marc.herbert-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
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
_______________________________________________
Iperf-users mailing list
Iperf-users-5NWGOfrQmnd4wTydcyPnfg@public.gmane.orgceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

------------------------------------------------------------------------------
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
Marc Herbert | 1 Dec 23:04 2010
Picon

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

Basavaraj Kapashi | 14 Dec 08:00 2010

iperf-2.0.5 UDP issues

Hi All

                Using cygwin I have compiled the iperf-2.0.5 for windows.

While testing UDP flow,  I have observed that sometimes  UDP receiver is not receiving the packets..

Please let me know how to fix this issue.

 

Regards,

==========================================

Basavaraj Kapashi

Larsen & Toubro Infotech Ltd.

E Mail id: basavaraj.kapashi-oonXi/34qI7c+919tysfdA@public.gmane.org

=========================================

 


The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. L&T Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail"

______________________________________________________________________
------------------------------------------------------------------------------
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

Gmane