Excerpts from ANSW (Anders Schwartzbach)'s message of Wed Apr 27 11:35:28 -0500 2011: > > Hi Jon > > I have just found your document on the internet: > > Using Iperf > Jon M. Dugan > <[email protected]> > NANOG 43, Brooklyn, NY > June 1, 2008 > > I would like to run a performace test - first in order to check the througput > on our 1gbps lines - second on our 10 gbps lines > > I get this result: > > netgrp@netgrp-test2:~$ iperf -c 192.168.133.101 -P 1 -i 5 -p 5001 -f m -t 600 > -r -L 5001 > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 0.08 MByte (default) > ------------------------------------------------------------ > ------------------------------------------------------------ > Client connecting to 192.168.133.101, TCP port 5001 > TCP window size: 0.07 MByte (default) > ------------------------------------------------------------ > [ 5] local 192.168.133.100 port 58148 connected with 192.168.133.101 port > 5001 > [ ID] Interval Transfer Bandwidth > [ 5] 0.0- 5.0 sec 552 MBytes 926 Mbits/sec > [ 5] 5.0-10.0 sec 559 MBytes 938 Mbits/sec > [ 5] 10.0-15.0 sec 559 MBytes 938 Mbits/sec > [ 5] 15.0-20.0 sec 558 MBytes 937 Mbits/sec > > But I would like very much to be sure, that IF I am losing frames - e.g. 1% I > will be able to detect it. > > Do you have any idea about have to inspect if we have any TCP (not UDP) > frames drops - is it standard for TCP?
Hello Anders, Typically I use UDP when I am testing circuits for loss precisely because I can measure loss easily with UDP. Usually I do this by counting UDP frames with firewall counters on each end of the circuit under test. In this setup I don't bother trying to receive the UDP packets on the remote side I just count them before and after they cross the circuit under test. This presupposes that the firewall counters are accurate which is not a good assumption for many vendors. Before trying this yourself be sure to verify that the routers or switches your using can actually count. I've spent far too much time with the tech support of a very well known vendor trying to track down problems with how the devices counts (or doesn't count) traffic. There isn't a standard way to see TCP loss; most OSes don't traditionally expose this information. To some extent this is because the point of TCP is to hide the messy details of reliable communication. That black box is very nice when it's working but when it comes time to troubleshoot things it can be problematic. There are two current ways to get what you're asking for the TCP_INFO getsockopt() call and Web100/Web10G. Some OSes include some additional information via the TCP_INFO getsockopt(). Recent Linux and FreeBSD kernels support TCP_INFO. Iperf3 (which is currently in development) supports getting information from from TCP_INFO. You can find iperf3 at http://code.google.com/p/iperf/ Currently the -T will show the number of retransmits, for example: toolshed:15> ./iperf3 -T -c localhost Connecting to host localhost, port 5201 [ 5] local 127.0.0.1 port 51200 connected to 127.0.0.1 port 5201 [ ID] Interval Transfer Bandwidth Sent [ 5] 0.00-5.00 sec 3.10 GBytes 5.33 Gbits/sec Received [ 5] 0.00-5.00 sec 3.10 GBytes 5.33 Gbits/sec TCP Info Retransmits: 0 I believe nuttcp also supports TCP_INFO. You can find it at: http://www.wcisd.hpc.mil/nuttcp/ The Web100 project and it's more recent follow on Web10G has also developed a comprehensive TCP extended statistics MIB that would give you this information. This however requires installing a custom kernel with Web100 support. The advantage here is that you can collect statistics for any program that uses TCP since it directly plugs into TCP machinery inside the kernel. For more information in Web10G, see the project's webpage at: http://web10g.org/. Hope that helps, Jon ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Iperf-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/iperf-users
