>From what I remember, iperf reports the bandwidth from each thread
separately but then combines all values into one value at the end of each
time-window. I think the combined value from all threads has "-1" in it (if
you enable csv); in that case, just grep for ",-1,".
-Mohammad
On Mon, Oct 14, 2013 at 5:43 AM, Upendra K <upendrakaranji1...@gmail.com>wrote:
> Hi Team
>
> I have one question ,
>
> !.>when i ran the iperf with 128 thread i am not getting the SUM value ,
>
> example :-
> server :- iperf -s -i 1 -B xx.xx.xx.xx |grep SUM
>
> client :- iperf -c xx.xx.xx. -B xx.xx.xx.xx -i 1 -P 128 |grep SUM
>
> But if remove the grep SUM , traffic goes fine
>
> Please find the below details :-
>
> iperf version :- 2.0.5
>
> Please let me know what is the issues , is this issues with the iperf.?
>
> Regards
> Upendra
>
>
>
>
> On Mon, Oct 14, 2013 at 6:19 AM, Mohammad Hajjat <haj...@purdue.edu>wrote:
>
>> Yeah I agree, it's not very clear what's going on! But don't you think
>> the 160 ms is a bit too high? Maybe the RTT you measure is different for
>> ping's ICMP than in TCP (which iperf uses by default)?
>>
>>
>> On Sun, Oct 13, 2013 at 8:13 PM, Nik Koracek <nkora...@tpg.com.au> wrote:
>>
>>> ** ** **
>>>
>>> Hi Mohammad,****
>>>
>>> ** **
>>>
>>> I can and I know that I am able to max out the link when I increase the
>>> window size and number of parallel streams. My test was focused on running
>>> a single tcp stream.****
>>>
>>> ** **
>>>
>>> My only concern is that I don’t understand the logic behind getting the
>>> results that I did. I would have expected to get 1.265Mbps with the test
>>> setup the way I described.****
>>>
>>> ** **
>>>
>>> I would like to understand how I was getting 65Mbps+ on that 160ms RTT
>>> link with those default window sizes.****
>>>
>>> ** **
>>>
>>> Cheers,****
>>>
>>> ** **
>>> ------------------------------
>>>
>>> *From:* Mohammad Hajjat [mailto:haj...@purdue.edu]
>>> *Sent:* Monday, 14 October 2013 11:00 AM
>>> *To:* Nik Koracek
>>> *Cc:* Mohammad Hajjat; iperf-users
>>>
>>> *Subject:* Re: [Iperf-users] Help understanding results from a single
>>> TCP session
>>> ****
>>>
>>> ** **
>>>
>>> I see, why can't you just increase iperf's window size? ****
>>>
>>> I had experiments where I had to set the window size in iperf to 16 MB
>>> to get an optimal bandwidth. ****
>>>
>>> ** **
>>>
>>> On Sun, Oct 13, 2013 at 7:08 PM, Nik Koracek <nkora...@tpg.com.au>
>>> wrote:****
>>>
>>> Hi Mohammad,****
>>>
>>> ****
>>>
>>> Thanks for the reply, sorry for any confusion.****
>>>
>>> ****
>>>
>>> During testing the client machine was using a default window size of
>>> 23.2 Kbytes, while the server machine was using a default window size of
>>> 85.3 Kbytes.****
>>>
>>> ****
>>>
>>> My question is, do you know how I could get in excess of 65Mbps on a
>>> single tcp session using the aforementioned window sizes between two
>>> devices that had a 160ms RTT between them?****
>>>
>>> ****
>>>
>>> Cheers****
>>>
>>> ****
>>> ------------------------------
>>>
>>> *From:* Mohammad Hajjat [mailto:haj...@purdue.edu]
>>> *Sent:* Monday, 14 October 2013 12:18 AM
>>> *To:* nkora...@tpg.com.au
>>> *Cc:* iperf-users
>>> *Subject:* Re: [Iperf-users] Help understanding results from a single
>>> TCP session****
>>>
>>> ****
>>>
>>> But your server's window size isn't 25 KB, is it?****
>>>
>>> Also, what is it in specific that you want to explain? I'm sorry I lost
>>> track :P****
>>>
>>> ****
>>>
>>> ****
>>>
>>> On Sun, Oct 13, 2013 at 7:46 AM, <nkora...@tpg.com.au> wrote:****
>>>
>>> Hi All,****
>>>
>>> ****
>>>
>>> I was troubleshooting a throughput issue recently on an international
>>> 300Mbps link which had a RTT of ~160ms. ****
>>>
>>> ****
>>>
>>> I have copied the output below from testing a single TCP session between
>>> two linux servers at either endpoint.****
>>>
>>> ****
>>>
>>> I have the output from two tests from the perspective of SERVER_A
>>> (acting first in server mode and then in client mode). The remote server
>>> had similar output and same window sizes i.e. when in server mode it
>>> defaulted to 85.3 Kbytes and when in client mode defaulted to 25.3 Kbytes.
>>> ****
>>>
>>> ****
>>>
>>> ********************************************************
>>>
>>> SERVER MODE (receiving connection from remote server)****
>>>
>>> ********************************************************
>>>
>>> ****
>>>
>>> [root@SERVER_A ~]# iperf -s -i 1****
>>>
>>> ------------------------------------------------------------****
>>>
>>> Server listening on TCP port 5001****
>>>
>>> TCP window size: 85.3 KByte (default)****
>>>
>>> ------------------------------------------------------------****
>>>
>>> [ 4] local 192.168.1.1 port 5001 connected with 192.168.2.1 port 46326*
>>> ***
>>>
>>> [ ID] Interval Transfer Bandwidth****
>>>
>>> [ 4] 0.0- 1.0 sec 491 KBytes 4.02 Mbits/sec****
>>>
>>> [ 4] 1.0- 2.0 sec 3.79 MBytes 31.8 Mbits/sec****
>>>
>>> [ 4] 2.0- 3.0 sec 9.13 MBytes 76.6 Mbits/sec****
>>>
>>> [ 4] 3.0- 4.0 sec 9.01 MBytes 75.6 Mbits/sec****
>>>
>>> [ 4] 4.0- 5.0 sec 9.01 MBytes 75.6 Mbits/sec****
>>>
>>> [ 4] 5.0- 6.0 sec 10.1 MBytes 84.6 Mbits/sec****
>>>
>>> [ 4] 6.0- 7.0 sec 9.00 MBytes 75.5 Mbits/sec****
>>>
>>> [ 4] 7.0- 8.0 sec 9.13 MBytes 76.6 Mbits/sec****
>>>
>>> [ 4] 8.0- 9.0 sec 9.01 MBytes 75.6 Mbits/sec****
>>>
>>> [ 4] 9.0-10.0 sec 9.02 MBytes 75.7 Mbits/sec****
>>>
>>> [ 4] 0.0-10.2 sec 79.8 MBytes 65.6 Mbits/sec****
>>>
>>> ****
>>>
>>> ********************************************************
>>>
>>> CLIENT MODE (sending data to remote server)****
>>>
>>> ********************************************************
>>>
>>> ****
>>>
>>> [root@SERVER_A~]iperf -c 192.168.2.1****
>>>
>>> ------------------------------------------------------------****
>>>
>>> Client connecting to 192.168.2.1, TCP port 5001****
>>>
>>> TCP window size: 23.2 KByte (default)****
>>>
>>> ------------------------------------------------------------****
>>>
>>> [ 3] local 192.168.1.1 port 56806 connected with 192.168.2.1 port 5001*
>>> ***
>>>
>>> [ ID] Interval Transfer Bandwidth****
>>>
>>> [ 3] 0.0-10.1 sec 116 MBytes 96.7 Mbits/sec****
>>>
>>> ****
>>>
>>> ****
>>>
>>> What I did not understand is how we were getting in excess of 65 Mbps
>>> using a single TCP session and default window size of 25.3 Kbytes.****
>>>
>>> ****
>>>
>>> From my calculations ****
>>>
>>> ****
>>>
>>> 1000ms/160ms = 6.25 window periods****
>>>
>>> 6.25 x window size (25.3Kbytes) = 158.125 Kbytes****
>>>
>>> multiplied by 8 to convert into Mbps is 1.265 Mbps****
>>>
>>> ****
>>>
>>> Any ideas on how to explain the logic behind these results given the
>>> testing setup described above?****
>>>
>>> ****
>>>
>>> Cheers****
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>>> from
>>> the latest Intel processors and coprocessors. See abstracts and register
>>> >
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Iperf-users mailing list
>>> Iperf-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/iperf-users****
>>>
>>>
>>>
>>> ****
>>>
>>> ****
>>>
>>> -- ****
>>>
>>> *Mohammad Hajjat*****
>>>
>>> *Ph.D. Student*****
>>>
>>> *Electrical and Computer Engineering*****
>>>
>>> *****Purdue**** University*******
>>>
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2013.0.3408 / Virus Database: 3222/6745 - Release Date: 10/12/13
>>> ****
>>>
>>>
>>>
>>> ****
>>>
>>> ** **
>>>
>>> -- ****
>>>
>>> *Mohammad Hajjat*****
>>>
>>> *Ph.D. Student*****
>>>
>>> *Electrical and Computer Engineering*****
>>>
>>> *****Purdue**** University*******
>>>
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2013.0.3408 / Virus Database: 3222/6747 - Release Date: 10/13/13
>>> ****
>>>
>>>
>>
>>
>> --
>> *Mohammad Hajjat*
>> *Ph.D. Student*
>> *Electrical and Computer Engineering*
>> *Purdue University*
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Iperf-users mailing list
>> Iperf-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>
>>
>
--
*Mohammad Hajjat*
*Ph.D. Student*
*Electrical and Computer Engineering*
*Purdue University*
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
