If memory serves me right, Michael Frimpong wrote: > A gentle reminder on below mail. Thank you.
Hi Michael-- Sorry for the delay...yes I'm still juggling stuff at work (iperf3 is a small portion of my time at my day job). Let's see here. You're running iperf-3.1.3. It would be really good if you can somehow be running a newer version, in particular 3.2 or newer (3.6 is the currently-released version). I am aware that newer Windows executables might be difficult to find, without going through the motions of compiling your own. iperf-3.2 and newer contain a number of buffer-handling and timing fixes that specifically improve functioning with UDP (in particular these newer versions of iperf3 emit smoother, less bursty streams of UDP datagrams, which helps avoid buffer overflows). >> On 14 Sep 2018, at 4:04 PM, Michael Frimpong <michaelfrimpon...@gmail.com> >> wrote: >> >> Hello Bruce, >> >> Just as your requested, I am using IPerf 3.1 as seen in the attached >> version details for both server and Client. Also when I try testing my >> bandwidth on a 1Gbps NIC, I am getting 0's at the server side and >> client side stuck at connecting to host as seen in the attached too. >> >> >> c:\>iperf3 -v >> iperf 3.1.3 >> CYGWIN_NT-6.3-WOW SERVER2-NMSII 2.5.1(0.297/5/3) 2016-04-21 22:12 i686 >> Optional features available: None OK, this looks good, modulo my comments about getting a newer version of iperf3. >> c:\>iperf3 -s >> ----------------------------------------------------------- >> Server listening on 5201 >> ----------------------------------------------------------- >> Accepted connection from 41.242.112.193, port 50758 >> [ 5] local 41.242.112.174 port 5201 connected to 41.242.112.193 port 49476 >> [ ID] Interval Transfer Bandwidth Jitter Lost/Total >> Datag >> rams >> [ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) >> [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) >> [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) >> [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) >> [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) >> [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) >> [ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) >> [ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) >> [ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) >> [ 5] 9.00-9.98 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bandwidth Jitter Lost/Total >> Datag In this case the server got a connection from the client, so you clearly have two-way connectivity between the server and the client. However it didn't get any UDP packets. I wonder if they are being blocked somehow? A frequent cause for this is a host-based firewall on one of the hosts. >> CLIENT SIDE >> >> c:\>iperf3 -v >> iperf 3.1.3 >> CYGWIN_NT-6.1-WOW Ibrahim-PC 2.5.1(0.297/5/3) 2016-04-21 22:12 i686 >> Optional features available: None >> >> >> >> c:\>iperf3 -u -c 41.242.112.177 -b900M -w128k -t15 >> Connecting to host 41.242.112.177, port 5201 >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bandwidth Jitter Lost/Total >> Datag >> rams It didn't print anything at all? That's very odd. It's hard for me to follow what your test cases are, since you're using both iperf2 and iperf3, and TCP and UDP tests with each. It sounds like going from iperf2 (what you were initially running) to iperf3 was a step backwards. On iperf2 you first said you were able to get some packets through, with some loss, then you said it was working, because on 14 August you wrote: > However, just this morning I tried running the test using Iperf 2.0.9 and it > seems to work. If things basically work with iperf2, maybe you should just use that. I would probably still want to increase the buffer sizes on the client and sender using the -w command-line option...that would probably reduce the amount of packet loss. Another thing to keep in mind. In the very first message you sent to me you said you were trying to troubleshoot some network issues with your customers. Remember that fundamentally both iperf2 and iperf3 are just transferring a bunch of bytes on either a TCP connection or a stream of UDP packets and computing an effective throughput based on those. You don't have to use one of these tools to measure performance. You could for example have a customer try to download a large file with a known size and have him/her report how long it takes; from the size and time you can compute the throughput of their download. Bruce. >> -----Original Message----- >> From: Bruce A. Mah [mailto:b...@es.net] >> Sent: Monday, August 20, 2018 3:26 PM >> To: Michael Frimpong <michaelfrimpon...@gmail.com> >> Subject: Re: IPERF NOT PROVIDING THE REQUIRED BANDWIDTHIf memory >> serves me right, Michael Frimpong wrote: >> >>> Trust you are doing great. Please I am trying to do the test and the >>> results for UDP are Ok but at the server side the bandwidth cannot go >>> above 500Mbps. >>> >>> >>> >>> Most of the datagrams are dropped as seen below and was wondering why >>> that is so? Can you help me on why most of the drops happen. >> >> Hi Michael-- >> >> Sorry for the delay...multi-tasking between multiple projects here. >> >> I am guessing a little bit here because there are some pieces of information >> I still don't have regarding your setup...but here we goi anyway... >> >> One common problem people run into with UDP tests is that they might need to >> increase the maximum buffer size, particularly on the receiver side. You >> can change this with the -w command-line flag, for example -w128k sets the >> buffer to 128KB. >> >> What happens if you run at lower bitrates (less than 1GB?)? >> >> I think to get any further with this I'll need a few more bits of >> information. Specifically; >> >> 1. The output of "iperf3 -v" on both the client and server sides, so I know >> exactly what versions you're running and what operating systems you are >> have. >> >> 2. The complete output from a short test, on both the client and server >> sides. Maybe 5 seconds (-t5)? It looks like this problem would show up >> with a much shorter test than what you are doing. >> >> Bruce. >> >> PS. As I'm looking through your email again, I'm not sure if you're on >> iperf2 or iperf3. This distinction is very important because (despite the >> similarity in names) they are totally separate problems. I know a fair >> amount about iperf3 but less about iperf2, and so I may not be able to help >> you further.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Iperf-users mailing list Iperf-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iperf-users
