The Limitation of Simple Ping Tests
When users complain that “the network is slow” or “the database is lagging,” the standard IT response is often to run a ping command. While ping will confirm if the server is reachable and provide basic latency metrics (round-trip time), it is completely blind to actual network capacity. A ping packet is only 64 bytes. A network link might successfully transmit a 64-byte ping in 2 milliseconds, but completely collapse when attempting to push a 5-gigabyte database backup across the same connection.
To accurately diagnose network bottlenecks, IT administrators must saturate the link with massive amounts of data to measure the maximum achievable throughput (bandwidth) and the variation in packet delay (jitter).
The industry-standard tool for this diagnostic stress testing is iperf3. Available on nearly all Linux distributions, iperf3 operates on a client-server model, injecting raw TCP or UDP data streams directly into the network stack to measure the true physical limitations of your infrastructure.
Step 1: Installing the Utility
Because iperf3 requires a sender and a receiver, you must install it on two different Linux machines (for example, a web server and a database server to test the link between them).
On Ubuntu or Debian:
sudo apt update
sudo apt install iperf3 -yOn RHEL or CentOS:
sudo yum install iperf3 -yStep 2: Starting the iperf3 Server
Decide which machine will act as the receiver (the server). Log into that machine and start the iperf3 daemon in server mode using the -s flag.
iperf3 -sThe output will state that it is Server listening on 5201. (Ensure your firewall, such as ufw or iptables, allows incoming traffic on TCP and UDP port 5201).
This server will now sit silently, waiting for a client to blast data at it.
Step 3: Executing a Standard TCP Bandwidth Test
Log into the second machine (the client). You will instruct it to connect to the server and transmit as much data as physically possible for 10 seconds.
Run the command using the -c (client) flag followed by the server’s IP address:
iperf3 -c 192.168.1.50The terminal will instantly begin outputting real-time statistics every second. After 10 seconds, it will provide a sender/receiver summary:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.10 GBytes 939 Mbits/sec receiverIn this example, the network achieved a throughput of 941 Megabits per second (Mbps). Since standard Gigabit Ethernet tops out at a theoretical 1000 Mbps (minus TCP overhead), this result proves the network switch and cables are functioning perfectly at full Gigabit speeds.
Notice the Retr (Retransmissions) column. If this number is high, it means the network switch is dropping TCP packets, forcing the client to resend them. High retransmissions indicate a failing switch port or severe network congestion.
Step 4: Testing UDP Jitter and Packet Loss
TCP is a reliable protocol; it automatically resends lost packets. For real-time applications like VoIP (Voice over IP) or live video streaming, TCP is not used. They use UDP, which blasts data without waiting for confirmation. For VoIP, bandwidth is irrelevant (audio is small), but Jitter (the variation in latency) and Packet Loss are critical. If jitter is high, the phone call sounds robotic.
To test UDP performance, append the -u flag.
iperf3 -c 192.168.1.50 -u -b 10MNotice the addition of -b 10M. Because UDP doesn’t have flow control, if you don’t specify a target bandwidth (Bitrate), iperf3 will simply default to 1 Mbps. Here, we are forcing it to blast 10 Megabits per second.
The output summary will look different:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 11.9 MBytes 10.0 Mbits/sec 0.024 ms 0/8512 (0%) receiverHere, the jitter is an incredibly low 0.024 milliseconds, and packet loss is 0%. This network is perfectly optimized for flawless VoIP communications.
Step 5: Simulating Multiple Concurrent Users
A single TCP stream doesn’t always reflect real-world load. If you are testing a load balancer or a high-capacity firewall, it might handle one massive connection perfectly, but choke when 50 different users try to connect simultaneously.
You can use the -P (Parallel) flag to instruct the client to spawn multiple concurrent TCP streams simultaneously.
iperf3 -c 192.168.1.50 -P 10This command will open 10 separate TCP connections, flooding the server, and then provide a combined summation of the total aggregated bandwidth.
Conclusion
iperf3 is the definitive command-line tool for proving network hardware capabilities. Before spending thousands of dollars upgrading a router or blaming an ISP for a slow database connection, system administrators must use iperf3 to generate empirical, undeniable metrics regarding maximum TCP throughput, UDP jitter, and hardware-level packet loss.