Measuring real LAN speed from a phone with iperf3

Disclosure before we start: I build the native iPerf3 apps for iPhone, iPad, Mac, and Android mentioned near the end. Everything in this post also works with the free iperf3 CLI on two computers. The phone enters the picture when one endpoint has to move around the building. Speedtest answers one question: how fast is the path from your device to the ISP's nearest test server. Inside a home or office a different question comes up: how fast is the link between the phone and the NAS, between two mesh nodes, between the office switch and the upstairs access point. Traffic between two local devices never leaves the LAN, so an internet speed test cannot see it. iperf3 measures that link. ESnet maintains it as a from-scratch redesign of the original iperf, and common Linux, BSD, and macOS package repositories carry it. How iperf3 measures iperf3 is a client-server tool. One device listens (iperf3 -s), the other connects to it, pushes traffic for a fixed duration, and counts what arrived. Because you control both endpoints, the result describes one specific link instead of a whole path across the internet. The server side installs in one line on Linux and macOS: # Debian/Ubuntu sudo apt install iperf3 && iperf3 -s # macOS brew install iperf3 && iperf3 -s ESnet does not publish or support native Windows binaries. If you need a Windows endpoint, check the upstream installation notes before choosing a third-party build. Some router and NAS platforms make iperf3 available through their package systems. Availability depends on the model and firmware, so check the package source before treating the appliance as a permanent server. A five-minute test Start the server on a wired device and note its LAN IP, for example 192.168.1.10. From the client, start with the default ten-second test. Use sixty seconds when you need to see changes caused by interference, roaming, or sustained load: iperf3 -c 192.168.1.10 -t 60 Read the receiver line at the end. That number is the throughput the link sustained. A healthy wired 1GbE TCP link often sustains about 930 to 950 Mbit/s after protocol overhead. Wi-Fi varies with channel width, spatial streams, interference, access-point configuration, and the phone's radio. Compare the same phone and settings across locations instead of judging a result from the Wi-Fi generation label alone. If a wired link reports far below its expected rate, check the negotiated link speed, cable, switch port, USB adapter, and CPU load on both endpoints. Now walk. Run the same test from the far bedroom, the garage, the conference room. The room-to-room gap is the thing a signal-strength bar hides. Which output fields to read Throughput is the headline number: application data delivered per second, usually shown in Mbit/s or Gbit/s. Retransmits (TCP) count segments the sender had to transmit again. A clean wired LAN should produce few retransmits. A rising count on repeated runs gives you a reason to isolate the cable, port, queueing, or wireless hop; the counter alone does not identify the cause. Jitter and packet loss appear in UDP mode. Set the target below the link's measured TCP capacity, then raise it in steps. For example: iperf3 -c 192.168.1.10 -u -b 100M -t 60 Packet loss and jitter affect calls and games before raw throughput becomes the obvious problem. Your acceptable limits depend on the application, codec, and traffic pattern. Traps that produce wrong numbers Both endpoints on Wi-Fi. You measure the weaker of two radio links plus their contention for airtime. Put the server on Ethernet and test the wireless hop you care about. USB Ethernet adapters. USB 2.0 adapters often top out around 300 to 350 Mbit/s in practice. Check the adapter and negotiated link speed before blaming the network. Short tests. Connection setup, TCP ramp-up, and brief interference can dominate a short result. Use longer runs when you care about stability under sustained load. A sleeping phone. Some phones reduce background network activity or suspend the test when the screen locks. Keep the app in the foreground and the screen on during a run. Running iperf3 on the phone itself The phone is often the endpoint that matters: it is the device the complaint is about, and it is the device you carry from room to room. Options for a native endpoint: iPhone / iPad / Mac: iPerf3 Client & Server on the App Store. One purchase ($6.99, one-time) covers iPhone, iPad, and Mac. Client and server modes, TCP/UDP, live charts, history, CSV/JSON export, Apple Shortcuts automation. Android: iPerf3 TCP/UDP Client & Server on Google Play ($3.99, one-time). Same idea: both modes, advanced parameters, export. Both apps use the iperf3 protocol, so a phone in server mode can accept tests from compatible iperf3 CLI versions and vice versa. If two endpoints fail to negotiate, compare their iperf3 versions before debugging the network. Two phones make a portable end-to-end test kit: put one in server mode and use the other as the client. Because both endpoints share Wi-Fi airtime, this setup cannot isolate mesh backhaul performance. Use a wired server when you need to test one wireless hop or compare rooms. Where to go deeper iperf3 upstream project (source, releases, and official documentation) How to test LAN speed, step by step Why Speedtest and iperf3 answer different questions Questions about a weird result are welcome in the comments; I read all of them.