headers
Marc Herbert | 1 Dec 2010 10:45
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)

Permalink | Reply |
headers
Usman S. Ansari | 1 Dec 2010 18:13
Picon
Favicon

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

Gmane