Testing UDP with iperf3: jitter, packet loss and bandwidth

Updated November 2026

A UDP test with iperf3 sends packets at a rate you choose and counts how many arrive, how late and how unevenly. It answers a different question from a TCP test: not "how fast can I go?" but "can this path carry a given rate cleanly?"

Why test with UDP

TCP slows down when it sees loss, so a TCP test hides loss inside a lower throughput figure. UDP has no congestion control: iperf3 keeps sending at the rate you set, and the receiver reports exactly what went missing. That makes UDP the right tool for questions such as:

Will this link carry a 20 Mbit/s video stream without dropping packets?
How much jitter (variation in delay) will a voice call see?
At what rate does a firewall, VPN or Wi-Fi link start to drop packets?

Running a UDP test

Start the server as usual. You do not need -u on the server; the client tells it what kind of test to run.

iperf3 -s

On the client, add -u and, most importantly, a target rate with -b:

iperf3 -c 192.0.2.10 -u -b 100M -l 1400 -t 10

Without -b, a UDP test runs at only 1 Mbit/s, which is the commonest reason for "my gigabit link does 1 Mbit/s with UDP". Use -R to send from the server to the client instead. The test data uses UDP on port 5201, but iperf3 also opens a TCP control connection to the same port, so a firewall must allow both.

Reading the results

The client (sender) prints how many datagrams it sent each second. The useful numbers are in the summary, where the receiver reports what arrived. Here is a trimmed example for the command above:

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   119 MBytes   100 Mbits/sec  0.000 ms  0/89286 (0%)  sender
[  5]   0.00-10.04  sec   118 MBytes  98.4 Mbits/sec  0.045 ms  1072/89286 (1.2%)  receiver

Transfer and Bitrate: At 100 Mbit/s for 10 seconds the client sends 1,000 megabits, or 125,000,000 bytes. With 1,400-byte datagrams that is 125,000,000 ÷ 1,400 ≈ 89,286 datagrams. iperf3 shows bytes in binary units, so 125,000,000 bytes appears as 119 MBytes.
Lost/Total Datagrams: 1,072 of 89,286 datagrams never arrived: 1,072 ÷ 89,286 ≈ 1.2%. iperf3 counts loss from gaps in the sequence numbers it puts in every packet.
Jitter: The smoothed average variation in packet transit time, in milliseconds. iperf3 uses the method from RTP (RFC 1889, now RFC 3550): each new difference moves the estimate one-sixteenth of the way, so a single late packet does not dominate.

If packets arrive in a different order than they were sent, iperf3 also prints a line such as "datagrams received out-of-order". A little reordering is normal on paths with several parallel links; a lot of it hurts TCP performance.

Choosing rate and packet size

Start below the link rate and step up. Run at 25%, 50%, 75% and 90% of the expected capacity. The rate where loss starts is the real limit for that path.
Remember -b is per stream. -P 4 -b 100M sends 400 Mbit/s in total.
Match the application's packet size. By default iperf3 picks a datagram size from the path MTU, falling back to 1,460 bytes. Voice packets are much smaller; use -l to test with a size closer to the real traffic. Small packets at a high rate stress routers and hosts far more than large ones.
Avoid fragmentation. A datagram larger than the path MTU minus headers is split into IP fragments, and losing one fragment loses the whole datagram. On a standard 1,500-byte path, keep -l at 1,472 bytes or less for IPv4 (1,500 − 20 IP − 8 UDP) and 1,452 for IPv6 (1,500 − 40 − 8). See MTU and MSS.
Very low rates need small packets. The iperf3 FAQ notes that rates below about 100 kbit/s need a smaller length, such as -l 100.
Long or very fast tests can overflow iperf3's 32-bit packet counters; add --udp-counters-64bit (both ends must run 3.1 or later).

Network loss or host loss?

At high rates, UDP loss often happens inside the receiving computer: its socket buffer fills before the application reads the packets. Before you blame the network:

Use iperf3 3.1.5 or later. The FAQ recommends trying a larger socket buffer, for example -w 2M, which fixed high-rate UDP loss on some hosts.
Run the same test between two hosts on the same switch. If loss appears there too, it is the hosts.
Watch CPU on both ends. One busy core can limit a UDP test long before the link does.
On Linux, compare the kernel's UDP receive-error counters (netstat -su or nstat) before and after a test.
Compare against TCP. If TCP reaches line rate without retransmissions but UDP shows loss, suspect the receiver.

Be careful on shared networks. UDP does not back off. A 1 Gbit/s UDP test across an office uplink or a home broadband line will crowd out everyone else for as long as it runs. Keep tests short, start low, and get permission before testing across networks you do not run.

When UDP results mislead

Some networks treat UDP differently from TCP: rate limits on UDP, policers on VPN concentrators, or Wi-Fi access points that handle bursts badly. A clean UDP result at 50 Mbit/s says the path can carry that rate of UDP; it does not prove TCP will reach the same figure, and the reverse is also true. For TCP behaviour, see Reading results.