Martin T je dne 21/08/14 15:12 napisal-a:
if I execute "iperf -c -fm -t 600 -i 60 -u -b 500m" and 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

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.

-- 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