How to Evaluate Linux Network Performance: Stop Guessing and Use Data

1. Four Dimensions of Network Performance

Network performance is measured by latency (round‑trip time in ms), throughput (actual data transferred per second, e.g., Mb/s), bandwidth (theoretical link capacity), and packet loss (percentage of lost packets). High latency or loss can dominate perceived slowness even when bandwidth appears sufficient.

2. Basic Tools

Linux ships with several utilities that can provide an initial view without installing third‑party software:

ping – measures latency; ping -c 10 192.168.1.1 shows min/avg/max; latency >10 ms usually indicates a problem.

ss (modern replacement for netstat) – inspects socket state; look at cwnd (congestion window) and rtt (real‑time latency). Small cwnd suggests bandwidth not fully utilized; rising rtt hints at queuing.

nstat – kernel network stack statistics; key fields are TcpRetransSegs (TCP retransmissions), TcpOutSegs, TcpInSegs, and UdpInErrors. Retransmission rate = TcpRetransSegs / TcpOutSegs; >0.5 % triggers an alarm, >2 % indicates serious issues.

ethtool – physical‑layer information; ethtool eth0 checks Speed, Duplex, Link detection to ensure the NIC negotiates the expected rate.

3. Benchmark Tools

For quantitative measurements, dedicated benchmark utilities are required:

iperf3 – TCP/UDP throughput testing. Server side: iperf3 -s Client side (TCP): iperf3 -c SERVER_IP -t 30 -P 4 The Sum column’s Bitrate shows actual throughput (≈940‑950 Mb/s on a 1 Gbps link). UDP mode: iperf3 -c SERVER_IP -u -b 1000M reports jitter and loss rate.

netperf – similar to iperf3 but supports more test modes, e.g., TCP_RR (request‑response) and TCP_CRR, useful for short‑connection workloads such as databases or APIs. Example:

netserver
netperf -H SERVER_IP -t TCP_RR -l 30

wrk – HTTP‑level load testing. Example: wrk -t12 -c400 -d30s http://SERVER_IP/ shows Requests/sec and latency distribution.

The guiding principle is to test at the layer where the problem appears.

4. Evaluation Workflow Example

Basic Link Check – Verify physical layer, then run:

ethtool eth0 | grep -E "Speed|Duplex|Link"
ping -c 20 TARGET_IP
mtr -r -c 10 TARGET_IP

Look for negotiated speed, latency, and obvious packet loss.

Single‑Stream Throughput Baseline – Run iperf3 single stream; if the result is <80 % of the hardware limit, further multi‑stream testing is unlikely to help.

Multi‑Stream & UDP Boundary – Test with multiple TCP streams and UDP at 80 % of line rate to discover the loss threshold where bandwidth saturates.

Application‑Layer Validation – Use wrk to confirm that the application can sustain the required request rate; if transport and link layers are fine but the service is still slow, the bottleneck is likely in the application code.

A complete evaluation report should include latency (min/avg/max), TCP throughput (single‑ and multi‑stream), UDP loss rate, and HTTP latency.