http://permalink.gmane.org/gmane.network.iperf.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.network.iperf.user/499 <pre>Hello all! I'm trying to use iperf to test my 3g netwrok's upload and download speed. However my 3g network allocates a private IP for my device. Which means in the normal case I can only start a TCP connection from my client. And I came to realize that when the iperf TCP connection has been established, the data can only be send from the client. So can I modify something so that I can initialize a TCP connection from my client while the data can be send from the server side? Thanks in advance. </pre> 江卓 2013-05-14T15:46:10 http://permalink.gmane.org/gmane.network.iperf.user/498 <pre>I've tried running iperf on my local network, and I've found that it's blocking in pthread_cond_wait, even if I pass "-P1" as an argument. The version I'm running is: $ iperf -v iperf version 2.0.5 (08 Jul 2010) pthreads This is on Ubuntu. Could this be related to a bug reported in the Debian package? http://sourceforge.net/tracker/?func=detail&amp;aid=3030938&amp;group_id=128336&amp;atid=711373 Full output of ltrace is below. $ ltrace iperf -c 10.30.0.131 -P1 __libc_start_main(0x401f00, 4, 0x7ffff260c4c8, 0x40ab20, 0x40abb0 &lt;unfinished ...&gt; sigemptyset(0x7ffff260c278) = 0 sigaction(15, 0x7ffff260c270, 0x7ffff260c310) = 0 sigemptyset(0x7ffff260c278) = 0 sigaction(2, 0x7ffff260c270, 0x7ffff260c310) = 0 sigemptyset(0x7ffff260c278) = 0 sigaction(14, 0x7ffff260c270, 0x7ffff260c310) = 0 signal(1</pre> Lorin Hochstein 2013-04-12T04:13:13 http://permalink.gmane.org/gmane.network.iperf.user/497 <pre>Marc, Ah, great idea! That would explain a lot, and it's not at all hard to imagine, since I'm using the 2.4 GHz band. I will connect the endpoints directly by ethernet and let you know the result. Charles McIntosh On Fri, Mar 15, 2013 at 4:14 AM, Marc Herbert &lt;marc.herbert-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;wrote: ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________ Iperf-users mailing list Iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org https://lists.sourceforge.net/lists/listinfo/iperf-users </pre> Charles McIntosh 2013-03-15T17:39:19 http://permalink.gmane.org/gmane.network.iperf.user/496 <pre>Hello, all! I'm having some trouble interpreting some strange Iperf UDP results I'm receiving. If I use the following code on a wireless link (whose endpoints are only about five feet apart): Server: iperf -s -u -l 1472 -i 1 Client: iperf -c &lt;IP&gt; -u -l 1472 -b 50m -t 60 I get some strange results from my per-second feedback. [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 0.0- 1.0 sec 5.40 MBytes 45.3 Mbits/sec 0.260 ms 37/ 3887 (0.95%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 1.0- 2.0 sec 4.75 MBytes 39.9 Mbits/sec 0.253 ms 328/ 3715 (8.8%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 2.0- 3.0 sec 6.44 MBytes 54.1 Mbits/sec 0.357 ms 516/ 5107 (10%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 3.0- 4.0 sec 5.39 MBytes 45.2 Mbits/sec 0.239 ms 476/ 4315 (11%) [ ID] Interval Transfer Bandwidth Jitter Lost</pre> Charles McIntosh 2013-03-14T22:02:33 http://permalink.gmane.org/gmane.network.iperf.user/495 <pre> Hi, We have a server hosted in the USA, and one in Australia - approx 230m/sec latency between them - If I run an iperf udp test, result is ~26Mb/sec, but with a iperf tcp test the best I can get is ~270Kbits/sec (Not matter what window size options I use) Is this to be expected? Cheers ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb_______________________________________________ Iperf-users mailing list Iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org https://lists.sourceforge.net/lists/listinfo/iperf-users </pre> CiscoNSP List 2013-02-28T23:48:04 http://permalink.gmane.org/gmane.network.iperf.user/494 <pre>Howdy! I'm quite sure that "dropping" devices will drop any kind of packet when in buffer full state. This is particularly true for layer 2 devices (such as Ethernet switches and/or adapters) who know nothing about IP stuff. If you're lucky this will not be a completely sporadic process if those devices know about QoS, such as TOS(Type Of Service). This behaviour will not show too extermely for TCP due to several factors: * TCP slow start. Transmit rate at the beginning is quite slow for TCP and if sender receives ACKs in timely fashion and no NACKs in between, the TX rate will get up. This is also governed by initial/maximum TCP window size. * as already mentioned in paragraph above, if there's a missing packet, receiving side of a TCP stream will request for retransmission by NACKing the missing packet. This will reduce transmission rate. * probably there are more factors If there's a box with too small buffer size on the link path (leaky wireless device being most suspicious</pre> Metod Kozelj 2013-02-25T14:59:48 http://permalink.gmane.org/gmane.network.iperf.user/493 <pre>Thanks for your response. We were coming to the conclusion that iperf must measure the buffer fill rate on the client side. I am glad that you can confirm this. On systems with larger buffers we can see the dynamics you described where iperf can initially fill the buffer rapidly then settles to the link bandwidth as the test progresses. When testing under UDP we are convinced that packets are flushed out of the buffer without being pulled into the radio. We are having difficulty determining if a similar buffer behavior is present with TCP traffic. Though such behavior may be better tolerated due to the TCP retry mechanism I am concerned that it would at least trigger more retries at the TCP level than necessary. Again, thanks. Regards, Mark From: Metod Kozelj [mailto:metod.kozelj-40KPbxRzku4&lt; at &gt;public.gmane.org] Sent: Monday, February 25, 2013 8:43 AM To: Hickman, Mark Cc: iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org Subject: Re: [Iperf-users] iperf: How does iperf -c xxxxx -1 y -b ??M</pre> Hickman, Mark 2013-02-25T14:16:36 http://permalink.gmane.org/gmane.network.iperf.user/492 <pre>Howdy! It seems like nobody answered this question. Or I never got the answer. Anyhow ... Hickman, Mark je dne 15/02/13 22:56 napisal-a: iperf as a perfect userland application does not have any idea about physical layer connectivity. Hence sending party measures bandwidth of pushing data into send buffers. It is known to iperf if layers below that (TCP/UDP; IP; ethernet or any other L2 technology; wire, wireless or any other L1 technology) drop data. The above statement does not imply which of the cases you enumerated is actually the correct. However, if the transmit device behaves (ie does not drop data due to buffer full), then one an observe typical behaviour: a surge of UL data with high peak throughput at the beginning and a drop to real L2 speed afterwards. Hence conclusion: iperf client measures the interval bandwidth by the amount of data it wrote do a buffer per interval If it was the second (iperf client measures the interval bandwidth by the amount of data the radio pulled out of th</pre> Metod Kozelj 2013-02-25T13:43:23 http://permalink.gmane.org/gmane.network.iperf.user/491 <pre>We are attempting to stress a wireless link and monitor the performance of the 802.11 protocol. We have one unit under test as a client that reports an interval bandwidth close to ??M while the server is reporting much lower bandwidths in each interval with high UDP packet loss. The wireshark data indicates significant 802.11 packet loss. A different client (PC) reports a bandwidth at each interval similar to the server report for the respective interval and the server does not report high UDP packet loss. The wireshark captures illustrate a similar effort of 802.11 retries retrying more times on a particular sequence frame resulting in lower drops. On the PC client, the client summary report for bandwidth is close to but never matches the server report even accounting for packet loss. We are confused about the inner workings of iperf which raises questions of the validity of the reports under these conditions. 1. Does the iperf client measure the interval bandwidth by the amount of data it wrot</pre> Hickman, Mark 2013-02-15T21:56:14 http://permalink.gmane.org/gmane.network.iperf.user/490 <pre>My apologies for not linking directly to the commit! https://github.com/colindean/iperf-jperf/commit/8029efaec1a873ec334548bf32125812c00409cc </pre> Colin Dean 2013-01-25T02:31:49 http://permalink.gmane.org/gmane.network.iperf.user/489 <pre>Hello, all, I've added some docs and build targets for creating a real jperf.app for jperf on OS X. It can also be packaged into a standard .dmg file for distribution. It does not include the iperf binary, instead relying on the user to install iperf via macports or homebrew. https://github.com/colindean/iperf-jperf If people like it, perhaps I'll submit a patch here on SF. However, it seems that the patch queue is very long and largely untouched in the past ~3-4 years. </pre> Colin Dean 2013-01-25T01:55:07 http://permalink.gmane.org/gmane.network.iperf.user/487 <pre>On Mon, Dec 17, 2012 at 7:36 PM, Steffen Dettmer &lt;steffen.dettmer-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: I took a look to the sources and found issues with buffer handling. 1. usage tells: -l, --len #[KM] length of buffer to read or write (default 8 KB) but code tells: main-&gt;mBufLen = 128 * 1024; // -l, 8 Kbyte mExtSettings-&gt;mBufLen = kDefault_UDPBufLen; with const int kDefault_UDPBufLen = 1470 For the first one it could be that a bug entry already exists in a tracker. 2. recv is used with a buffer of that size, which is too small to take UDP packets in general (they can be up to almost 64KB), see man recv: If a message is too long to fit in the supplied buffer, excess bytes may be discarded depending on the type of socket the message is received from. [...] MSG_TRUNC Return the real length of the packet, even when it was longer than the passed buffer. Only valid for packet sockets. </pre> Steffen Dettmer 2012-12-17T19:13:20 http://permalink.gmane.org/gmane.network.iperf.user/486 <pre>On Mon, Dec 17, 2012 at 1:36 PM, Steffen Dettmer &lt;steffen.dettmer-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: Did you make sure to start the server with a -l arg which matches the client? Eg, iperf -s -u -l 8900 Drew ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Iperf-users mailing list Iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org https://lists.sourceforge.net/lists/listinfo/iperf-users </pre> Andrew Gallatin 2012-12-17T19:06:38 http://permalink.gmane.org/gmane.network.iperf.user/485 <pre>Hi, the larger values I use for -l in UDP mode, the lower bandwidth is reported by iperf, incorrectly I think. With tcpdump I found that it really seems like iperf would calculate only with one IP fragement instead of the whole UDP packet. I hope someone can explain why this happens, but first let me explain what I did. I wondered why bandwidth decreases when using larger UDP frames: iperf -u -c x.y.0.1 -f m -b30m -l 1400 [ 3] 0.0-10.4 sec 4.01 MBytes 3.25 Mbits/sec 4.203 ms 23810/26811 (89%) iperf -u -c x.y.0.1 -f m -b30m -l 8000 [ 3] 0.0-10.3 sec 0.78 MBytes 0.63 Mbits/sec 9.625 ms 4129/ 4683 (88%) Server is iperf-2.0.5, downloaded just a few minutes ago. So with larger UDP packets, the reported bandwidth decreases from 3.25 Mbit/sec down to 0.63 MBit/sec. With tcpdump on an intermediate router and wireshark I found in IO Graphs for both the same data rate (~3Mbit). - First case, 1400 bytes UDP packets: - iperf tells 4.01 MBytes 3.25 Mbits/sec 23810/26811 (1400bytes), that are 3001 </pre> Steffen Dettmer 2012-12-17T18:36:13 http://permalink.gmane.org/gmane.network.iperf.user/484 <pre>Marc, I don't think that this is relevant in this case because all interfaces are in a separate broadcast domain(separate virtual LAN). For example if I do "ping -c1 10.10.1.1" in T42 machine and run "tcpdump -nei eth0" in T42 at the same time, I see only one ARP reply as expected: 01:06:39.349959 00:16:41:54:01:93 &gt; ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 534, p 0, ethertype ARP, Request who-has 10.10.1.1 tell 10.10.1.2, length 28 01:06:39.350147 00:15:58:2a:84:3e &gt; 00:16:41:54:01:93, ethertype 802.1Q (0x8100), length 64: vlan 534, p 0, ethertype ARP, Reply 10.10.1.1 is-at 00:15:58:2a:84:3e, length 46 Turned out, that the problem was with the switch interface MTU- it was smaller than laptop interfaces had. I increased the MTU and now iperf works. regards, Martin 2012/12/10, Marc Herbert &lt;marc.herbert-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;: ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Fr</pre> Martin T 2012-12-11T23:19:19 http://permalink.gmane.org/gmane.network.iperf.user/483 <pre>Could this be relevant to your case? http://www.embedded-bits.co.uk/2008/multiple-network-gotcha/ 2012/12/9 Martin T &lt;m4rtntns-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;: ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Iperf-users mailing list Iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org https://lists.sourceforge.net/lists/listinfo/iperf-users </pre> Marc Herbert 2012-12-10T00:59:53 http://permalink.gmane.org/gmane.network.iperf.user/482 <pre>Hello, I have a following simple network topology consisting of two laptops and one L2 switch facing with trunk ports to laptops: T60[eth0] &lt;-&gt; switch &lt;-&gt; [eth0]T42 Both T60 and T42 machines have three sub-interfaces: T60:~ # ip addr show | grep "eth0.[0-9]*$" inet 10.10.1.1/24 brd 10.10.1.255 scope global eth0.534 inet 10.10.2.1/24 brd 10.10.2.255 scope global eth0.541 inet 10.10.3.1/24 brd 10.10.3.255 scope global eth0.653 T60:~ # T42 ~ # ip addr show | grep "eth0.[0-9]*$" inet 10.10.1.2/24 brd 10.10.1.255 scope global eth0.534 inet 10.10.2.2/24 brd 10.10.2.255 scope global eth0.541 inet 10.10.3.2/24 brd 10.10.3.255 scope global eth0.653 T42 ~ # ..and L3 connectivity between laptops works fine: T60:~ # ping -I 10.10.1.1 -qc10 10.10.1.2 PING 10.10.1.2 (10.10.1.2) from 10.10.1.1 : 56(84) bytes of data. --- 10.10.1.2 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 8999ms rtt min/avg/max/mdev = 0.271/0.349/0.436/0.047 ms T60:~ # ping -I 10.10.2.</pre> Martin T 2012-12-09T22:15:17 http://permalink.gmane.org/gmane.network.iperf.user/481 <pre>Hi again I have found that if I add a sleep into the loop the server reports the correct numbers: #!/bin/bash iperf -u -s &gt; /dev/null &amp; for i in {1..5}; do iperf -u -c localhost -t 1 sleep 1 done Isn't it possible to include some connection ID in the UDP message that is incremented for each run? Or maybe a timestamp so that the client can tell the server when a new run begins. Best regards Ramon ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Iperf-users mailing list Iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org https://lists.sourceforge.net/lists/listinfo/iperf-users </pre> Ramon Hofer 2012-12-09T14:34:42 http://permalink.gmane.org/gmane.network.iperf.user/480 <pre>Hello, I'm experiencing really low TCP UL throughput numbers when testing with a 5 GHz 40 MHz channel width network in an isolated environment. With 40 MHz channel width, my TCP UL is ~45 megabits/s and with 20 MHz it is ~41 megabits/s. Any logs that would help with troubleshooting this I am more than happy to provide. I appreciated any help. Thanks, Parth ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d_______________________________________________ Iperf-users mailing list Iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org https://lists.sourceforge.net/lists/listinfo/iperf-users </pre> Parth Gajaria 2012-12-06T18:10:09 http://permalink.gmane.org/gmane.network.iperf.user/479 <pre>Hi all I need to test an adhoc wlan connection and use iperf alongside with other tools like ping, iwconfig, etc. So that iperf has it's own timeslot I use it in a loop with the -t option. When I do that the reported speed drops because iperf uses a longer time after each run. With this script: #!/bin/bash iperf -u -s &gt; /dev/null &amp; for i in {1..5}; do iperf -u -c localhost -t 1 done With "iperf version 2.0.5 (08 Jul 2010) pthreads" I get the following output. Please see that the time of the server report is incremented and the Bandwidth drops because of that. ------------------------------------------------------------ Client connecting to localhost, UDP port 5001 Sending 1470 byte datagrams UDP buffer size: 224 KByte (default) ------------------------------------------------------------ [ 3] local 127.0.0.1 port 51709 connected with 127.0.0.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 131 KBytes 1.05 Mbits/sec [ 3] Sen</pre> Ramon Hofer 2012-11-15T15:58:50 http://permalink.gmane.org/gmane.network.iperf.user/478 <pre>Hello All, First time posting here,but long time user of CentOS Linux. Hardware- ASRock E350M1 mini-itx mobo onboard Realtek rtl8111e (rev 02) nic #eth1 - internet pci-e Realteck rtl8111e (rev 06) nic #eth0 - lan # changed from the default r8169 driver to the correct r8168 driver that this particular nic(s) are known to have problems,,even after three years on CentOS 5.x and CentOS 6.x. This made no change in the iperf results, for completeness. Also- Vonage phone behind this server - for completeness. OS- CentOS 6.3 32-bit Problem - On my new build server of CentOS 6.3 and running asterisk i am getting bad voip quality on both astersik phones and my Vonage phone. I never had this problem on my old server, go figure. The remote end hears me badly most of the time, I can always hear the remote end fine. Troubleshoot - I was trying to get familiar with trying to setup an tc_htb setup to do QoS to at least my Vonage phone. Now before things get carried away I try and do some iperf runs from my new</pre> Barry R Cisna 2012-11-12T20:29:19 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.iperf.user