How to measure bandwidth and network routes with iperf3

Why measure real throughput on your local network?

Often, we subscribe to high-speed internet plans or set up robust corporate networks, but the actual transfer speed of large files remains sluggish. In practice, throughput—which represents the effective amount of data successfully transmitted per second—is usually much lower than the theoretical speed advertised by router or switch manufacturers. This happens because damaged cables, electromagnetic interference, and processing bottlenecks in client devices conceal the true performance of the infrastructure.

To discover exactly what is going on, system administrators and tech enthusiasts turn to iperf3, a widely used command-line utility for stressing network links and measuring their maximum capacity. Unlike simple browser speed tests, it forces data traffic directly between two machines, allowing you to isolate hardware issues or configuration flaws. If you have ever tried diagnosing similar issues with our guide on how to diagnose packet loss and routing issues with mtr, you know that measuring bandwidth requires surgical precision and controlled tests.

Preparing the environment and understanding the client-server architecture

The operation of iperf3 relies on a client-server model. In practice, this means you need at least two machines connected to the same network to perform the test: one will act solely by listening for incoming connections, while the other will push an intense data stream to measure the resistance and speed of the path. This separation ensures that the results reflect the actual capacity of the transmission medium, eliminating unwanted variables.

To get started, install the utility on both computers using your Linux distribution package manager, such as apt on Ubuntu or Debian, or its equivalent on your operating system. Once installed, choose the machine that will act as the receiver, open the terminal, and run the listening command. This initial process opens a dedicated communication port—by default, port 5201—waiting for the packets that will be fired by the client machine during the experiment.

Running the iperf3 server on the destination machine

The first practical step on the test bench is putting the receiver into standby mode. On the machine that will act as the server, type the command below in the terminal and press Enter. The tool will run in the foreground, displaying on the screen all incoming connections and partial results of each test performed.

iperf3 -s

If your network has strict firewall rules, remember to open TCP and UDP port 5201 to allow traffic between the two nodes. In practice, keeping the server active allows you to run multiple tests in a row from different clients on the local network, making it easier to compare performance across various access points, different network cables, or varied Wi-Fi adapters.

Firing traffic tests from the client machine

With the server active and waiting for connections, go to the second machine on the network, which will assume the client role, and point the iperf3 command to the server IP address. The following command initiates a standard transfer using the TCP protocol for ten seconds, continuously injecting data to calculate available bandwidth.

iperf3 -c 192.168.1.50

Replace the example IP address with the actual IP of the machine where you started the server. At the end of the countdown, the terminal will display a detailed report containing the total amount of data transferred and the average transfer rate obtained, usually expressed in Megabits per second (Mbps) or Gigabits per second (Gbps). These numbers serve as a baseline to evaluate whether your network cables are operating at full Gigabit speed or if there has been a fallback to the 100 Mbps Fast Ethernet standard.

Analyzing UDP traffic behavior and packet loss

Although the TCP protocol is excellent for measuring maximum speed under ideal guaranteed delivery conditions, it tends to mask intermittent instability issues. To evaluate the true robustness of the link against interference, we can force the use of the UDP protocol by adding the -u flag to the client command, along with specifying a target bandwidth for the test.

iperf3 -c 192.168.1.50 -u -b 100M

In this scenario, the tool sends a steady stream of UDP packets at a rate of 100 Megabits per second. At the end, the report will indicate not only the achieved throughput rate but also the exact percentage of packets lost along the way and the delay variation, known as jitter. If packet loss is high on a wired network, there is likely physical damage to the infrastructure, requiring detailed inspections or spot checks like those discussed in materials about how to test electrolytic capacitors on board with a meter when issues stem from unstable power delivery on aging network interface cards.

Identifying hidden bottlenecks and interpreting reports

Properly interpreting iperf3 results requires attention to details in the final report, specifically the time interval columns, cumulative transfer, and instantaneous bandwidth. If you notice sudden drops in transfer rate across the seconds of the test, this usually indicates buffer saturation in intermediary routers or temporary electromagnetic interference in poorly shielded cables running close to electrical power sources.

Another critical factor to observe is CPU resource consumption during command execution. Because iperf3 generates high-speed traffic, very old computers or virtualized servers with core limits may suffer processing bottlenecks before reaching the actual limit of the network interface. In such cases, the observed sluggishness is not a cable bandwidth issue, but rather a computational limitation in pushing packets through the operating system's TCP/IP stack.

Conclusion

Mastering iperf3 transforms how you diagnose and optimize local networks, replacing vague assumptions with precise, quantifiable data. By isolating TCP and UDP link behavior, it becomes much easier to identify whether slow file transfers stem from physical infrastructure issues, switch configuration flaws, or terminal hardware limitations. Integrating this testing routine into your daily workflow ensures a resilient, predictable network infrastructure ready to handle large data volumes.