Network Performance Monitoring: Introduction
Network Performance Monitoring is essential for addressing complex performance issues in networks. By solving these problems, you can gain a comprehensive understanding of your entire network architecture. Employing effective throughput and data flow testing tools can expedite the identification of issues. This article continues from previous discussions, focusing on the use of netperf and netstat for optimal Network Performance Monitoring.
More Information
Network Performance Monitoring: Throughput Measurement Insights
(Continued from above)
netperf
netperf is a versatile tool developed by HP, freely available for various Unix platforms and has also been ported to Windows. While it may not be as commonly used as ttcp, it has undergone extensive testing, making it a reliable choice for Network Performance Monitoring.
Unlike ttcp, the client and server are separate programs. The server is netserver, which can be started separately or through inetd. The client is netperf. In the following example, the server and client are started on the same machine:
bsd1# netserver
Starting netserver at port 12865
bsd1# netperf
TCP STREAM TEST to localhost : histogram
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
16384 16384 16384 10.00 326.10
The loop-back interface was tested and the report showed a throughput of 326Mbps.
In the following example, netserver is started on the host:
bsd1# netserver
Starting netserver at port 12865
netperf加上-H选项指定服务器地址：
bsd2# netperf -H 205.153.60.247
TCP STREAM TEST to 205.153.60.247 : histogram
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
16384 16384 16384 10.01 6.86
This is roughly the same throughput as ttcp. netperf also performs some additional tests. In the following tests, the transaction rate of the connection is also calculated:
bsd2# netperf -H 205.153.60.247 -tTCP_RR
TCP REQUEST/RESPONSE TEST to 205.153.60.247 : histogram
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 16384 1 1 10.00 655.84
16384 16384
The program contains some test scripts. You can also use netperf to do various flow tests.
iperf
If netperf or ttcp do not fulfill your Network Performance Monitoring needs, consider using iperf. This powerful tool can also evaluate UDP bandwidth, loss rate, and jitter. With a user-friendly Java front end, iperf is easy to use and has been successfully ported to Windows.
The following example runs the iperf server:
bsd2# iperf -s -p3000
------------------------------------------------------------
Server listening on TCP port 3000
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 4] local 172.16.2.236 port 3000 connected with 205.153.63.30 port 1133
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 5.6 MBytes 4.5 Mbits/sec
^C
The following example runs the client on Windows:
C:\>iperf -c205.153.60.236
-p3000
------------------------------------------------------------
Client connecting to 205.153.60.236, TCP port 3000
TCP window size: 8.0 KByte (default)
------------------------------------------------------------
[ 28] local 205.153.63.30 port 1133 connected with 205.153.60.236 port 3000
[ ID] Interval Transfer Bandwidth
[ 28] 0.0-10.0 sec 5.6 MBytes 4.5 Mbits/sec
Note the use of Ctrl-C to terminate the server. In TCP mode, iperf is equivalent to ttcp, so it can be used as a client or server.
Using iperf is particularly handy when investigating whether the TCP window is large enough. The -w option sets the socket buffer size. For TCP, this is the window size. With the -w option, the user can step through various window sizes to see how they affect throughput.
Other Tools
Consider exploring related tools for enhanced Network Performance Monitoring. For instance, treno employs a technique similar to traceroute to calculate block size, path MTU, and minimum RTP, providing valuable insights for network optimization. As shown in the following example:
bsd2# treno 205.153.63.30
MTU=8166 MTU=4352 MTU=2002 MTU=1492 ..........
Replies were from sloan.lander.edu [205.153.63.30]
Average rate: 3868.14 kbp/s (3380 pkts in + 42 lost = 1.2%) in 10.07 s
Equilibrium rate: 0 kbp/s (0 pkts in + 0 lost = 0%) in 0 s
Path properties: min RTT was 13.58 ms, path MTU was 1440 bytes
XXX Calibration checks are still under construction, use –v
Generally speaking, netperf, iperf, and treno provide richer features, but ttcp is easier to find.
Traffic measurement via netstat:
In ideal conditions, throughput should closely match bandwidth, taking overhead into account. However, when throughput falls short, understanding the discrepancies becomes crucial. This may stem from hardware or software issues, but is often attributed to other traffic on the network. If the cause remains unclear, the next step in Network Performance Monitoring is to analyze your network traffic.
There are three basic approaches to this. The first, and quickest, is to use a tool like netstat to look at the link behavior. Or to capture packets to look at the data flow. Finally, you can use an SNMP-based tool like ntop.
To get a snapshot of the data flow on the network, use the -i option. For example:
bsd2# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lp0* 1500 <Link> 0 0 0 0 0
ep0 1500 <Link> 00.60.97.06.22.22 13971293 0 1223799 1 0
ep0 1500 205.153.63 bsd2 13971293 0 1223799 1 0
tun0* 1500 <Link> 0 0 0 0 0
sl0* 552 <Link> 0 0 0 0 0
ppp0* 1500 <Link> 0 0 0 0 0
lo0 16384 <Link> 234 0 234 0 0
lo0 16384 127 localhost 234 0 234 0 0
The output shows the number of packets processed by each interface since the last reboot. In this example, interface ep0 received 13,971,293 packets (Ipkts) without errors (Ierrs), sent 1,223,799 packets (Opkts), had 1 error, and had no collisions (Coll). A small number of errors is usually not a cause for alarms, but the proportion of each error should be kept low and should be significantly less than 0.1% of the total number of packets. Collisions can be slightly higher, but should be less than 10% of the total traffic. The number of collisions includes only those that affect the interface. A high number of collisions indicates that the network is heavily loaded and the user should consider segmentation. Collisions only occur on certain media.
If you only want output for a single interface, you can specify it with the -I option, like:
bsd2# netstat -Iep0
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
ep0 1500 <Link> 00.60.97.06.22.22 13971838 0 1223818 1 0
ep0 1500 205.153.63 bsd2 13971838 0 1223818 1 0
The output may look slightly different depending on the implementation, but the basic information is the same. For example, the output on Linux is:
lnx1# netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 7366003 0 0 0 93092 0 0 0 BMRU
eth1 1500 0 289211 0 0 0 18581 0 0 0 BRU
lo 3924 0 123 0 0 0 123 0 0 0 LRU
As shown in the example above, Linux divides lost packets into three directories: errors , drops, and overruns.
Inconveniently, the values returned by netstat are cumulative since the last time the system was rebooted. What we really care about is how these values have changed recently, because if a problem is developing, it may take quite a while before it grows large enough to become a problem.
Sometimes you will want to do some stress testing on the system to see if errors increase, you can use ping with the -I option or the spray command.
First, run netstat to get the current value:
bsd2# netstat -Iep0
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
ep0 1500 <Link> 00.60.97.06.22.22 13978296 0 1228137 1 0
ep0 1500 205.153.63 bsd2 13978296 0 1228137 1 0
Next, send a large number of packets to the destination address. In this example, 1000 UDP packets are sent:
bsd1# spray -c1000 205.153.63.239
sending 1000 packets of lnth 86 to 205.153.63.239 ...
in 0.09 seconds elapsed time
464 packets (46.40%) dropped
Sent: 11267 packets/sec, 946.3K bytes/sec
Rcvd: 6039 packets/sec, 507.2K bytes/sec
Note that this test exceeded the network capacity, as 464 packets were dropped. This could mean that the network is congested. More likely, the host is trying to communicate with a slow device. When spray was run in the reverse direction, no packets were dropped.
Finally, go back to netstat to see if there is a problem:
bsd2# netstat -Iep0
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
ep0 1500 <Link> 00.60.97.06.22.22 13978964 0 1228156 1 0
ep0 1500 205.153.63 bsd2 13978964 0 1228156 1 0
This example shows no problem.
If there are problems with the display, you can get them by using the -s option. The amount of data output can be a bit daunting, but it provides a wealth of information. The information is segmented by protocol and error type, such as bad checksum or incomplete header.
On some systems, two -s options display the sum of non-zero values, as shown below:
bsd2# netstat -s -s
ip:
255 total packets received
255 packets for this host
114 packets sent from this host
icmp:
ICMP address mask responses are disabled
igmp:
tcp:
107 packets sent
81 data packets (8272 bytes)
26 ack-only packets (25 delayed)
140 packets received
77 acks (for 8271 bytes)
86 packets (153 bytes) received in-sequence
1 connection accept
1 connection established (including accepts)
77 segments updated rtt (of 78 attempts)
2 correct ACK header predictions
62 correct data packet header predictions
udp:
115 datagrams received
108 broadcast/multicast datagrams dropped due to no socket
7 delivered
7 datagrams output
The -p option is used to display summary information of a protocol. The following example displays statistics of TCP with non-zero values:
bsd2# netstat -p tcp -s -s
tcp:
147 packets sent
121 data packets (10513 bytes)
26 ack-only packets (25 delayed)
205 packets received
116 acks (for 10512 bytes)
122 packets (191 bytes) received in-sequence
1 connection accept
1 connection established (including accepts)
116 segments updated rtt (of 117 attempts)
2 correct ACK header predictions
88 correct data packet header predictions
Interpreting this result requires some experience. Start by looking at the large number of error messages. Next, identify the type of error. Typically, input errors are due to hardware failures. Output errors are caused by problems on the local host. Data corruption, such as bad checksums , usually occurs on the server. Conflicts often mean network congestion . Of course, this is only a general case.