Can you show the full transaction for both the client and the server (including the command, connects, etc.?) If there is a firewall such that the client can't reach the server it should fail on connect (for both UDP and TCP.)
Also, there is an iperf2 which has some fixes with respect to reporting. (Linux testing only) https://sourceforge.net/projects/iperf2/?source=directory Bob -----Original Message----- From: Martin T [mailto:[email protected]] Sent: Thursday, August 21, 2014 7:52 AM To: Metod Kozelj Cc: [email protected] Subject: Re: [Iperf-users] Iperf client 2.0.5 shows unrealistic bandwidth results if Iperf server is unreachable Metod, but shouldn't the Iperf client send out traffic at 500Mbps as I had "-b 500m" specified? In my example is prints unrealistic bandwidth(~60Gbps) results. regards, Martin On 8/21/14, Metod Kozelj <[email protected]> wrote: > Hi, > > Martin T je dne 21/08/14 15:12 napisal-a: >> if I execute "iperf -c 10.10.10.1 -fm -t 600 -i 60 -u -b 500m" and >> 10.10.10.1 is behind the firewall so that Iperf client is not able to >> reach it, then I will see following results printed by Iperf client: >> >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0 - 60.0 sec 422744 MBytes 59104 Mbits/sec >> [ 3] 60.0 - 120.0 sec 435030 MBytes 60822 Mbits/sec >> etc >> >> >> Why does Iperf client behave like that? Is this a know bug? > > That's not a bug in iperf, it's how UDP is working. The main difference > between TCP and UDP is that with TCP, IP stack itself takes care of all the > > details (such as in-order delivery, retransmissions, rate adaption, ...), > while with UDP stack that's responsibility of application. The only > functionality that iperf application does when using UDP is to fetch the > server (receiving side) report at the end of transmission. Even this > function > is not performed in perfect way ... sending side only waits for server > report > for short time and if it filled network buffers, this waiting time can be > too > short. > > The same phenomenon can be seen if there's a bottleneck somewhere between > the > nodes and you try to push datarate too high ... routers at either side of > the > bottle will discard packets when their TX buffers get filled up. If TCP was > > used, this would trigger retransmission in IP stack and all of > TCP-slow-start > would kick in and sending application would notice drop in throughput. If > UDP > was used, IP stack would not react in any way and application would dump > data > at top speed. > -- > > Peace! > Mkx > > -- perl -e 'print > $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' > -- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlb xq | dc > > ------------------------------------------------------------------------------ > > BOFH excuse #252: > > Our ISP is having {switching,routing,SMDS,frame relay} problems > > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Iperf-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/iperf-users ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Iperf-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/iperf-users
