No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

FAQ-How can actual Ethernet service bandwidths be simply tested

Publication Date:  2012-07-25 Views:  73 Downloads:  0
Issue Description
During engineering or Ethernet troubleshooting, you often need to test the make-break ratio, actual bandwidth, and packet loss ratio of an Ethernet service. The make-break ratio can be tested by using the ping command, test frame or OAM. No special test equipment, however, is available to test the actual service bandwidth or solve a packet loss fault, except the remote monitor (RMON). This case describes a simple testing method for solving a packet loss fault. 
Alarm Information
The RMON monitors the statistics on all the data frames that have been transmitted and received. In addition, the traffic threshold-crossing alarm can be reported provided that the equipment supports the alarm. 
Handling Process
Use iperf as follows:
1. Copy iperf to a hard disk, such as D:\.
2. Run iperf on the two PCs. Set one PC as the server and the other PC as the client.
To run iperf in server mode, type iperf �s, such as:
D:\>iperf �s
To run iperf in client mode, type iperf �c ipaddress (ipaddress indicates the IP address of the server PC), such as:
D:\>iperf �c serveripaddress
3. The two PCs automatically run iperf to complete the test procedure. By default, iperf uses TCP port 5001 (the port on the server side is 5001 and the port on the client side is a random choice). The results are as follows:
Server side:
D:\>iperf �s
Server listening on TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1896] local 10.12.10.11 port 5001 connected with 10.12.10.28 port 1765
[ ID] Interval Transfer Bandwidth
[1896] 0.0-10.0 sec 107 MBytes 94.7 Mbits/sec
Client side:
D:\>iperf -c 10.12.10.11
------------------------------------------------------------
Client connecting to 10.12.10.11, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1916] local 10.12.10.28 port 1765 connected with 10.12.10.11 port 5001
[ ID] Interval Transfer Bandwidth
[1916] 0.0-10.0 sec 107 MBytes 94.7 Mbits/sec
The results show that the bandwidth is 94.7 Mbps (for the connection at 100 Mbps). The test results vary with the Ethernet services.
4. By default, iperf uses TCP. To use UDP, set the -u option. To specify a port, use the -p option. Those two options help with firewall tests. In addition, to query iperf help, use the -h option. The other options of iperf are not discussed because the OptiX products currently support few Ethernet features. 
 
Root Cause
The iperf.exe file is an MS-DOS�based little program for measuring network performance. To use the program to test an Ethernet service, run the program on the test PCs on both sides of the service. 
Suggestions
Note:
1. The iperf program is imprecise in bandwidth measurement. For example, a bundle of five VC-12s have a bandwidth of 10 Mbps. The program may test the bandwidth as 9 Mbps. Therefore, iperf does not apply to the tests that require high precision. To obtain precise test results, use special test equipment or software, such as Solarwind or Chriot. The test software can be found on the Internet.
2. The iperf program can also verify the QoS function of an OptiX data board at low but explanatory precision.
3. The iperf program is inaccurate in testing a bandwidth of 1,000 Mbps or higher. The program operation depends on the PC performance. Even when the network interface on the PC is 1000 Mbps, the PC bus does not support the rate. Therefore, do not use iperf to test a bandwidth of 1,000 Mbps or higher.
4. The iperf program also helps solve a packet loss fault by verifying the actual bandwidth for each protocol type of packet. If iperf verifies that the equipment sets no limit to the bandwidth for processing each protocol, do as follows. Analyze the protocols running on the service link by using a special packet capture and analysis tool, such as Sniffer or Ethereal. The analysis is complex and assumes that you well know all the data protocols. This case does not address the analysis.
5. There are also other similar little test programs, such as WTCP. WTCP and iperf work similarly and have similar effects. Leaning one of them is enough.
6. The iperf program mainly tests bandwidths. Before the test, confirm the service connectivity, for example, by using the ping command. 
 

END