How to Measure Jitter and Packet Loss With iPerf3
Video calls stutter while speed tests look fine. Run an iperf3 UDP test from the device you take calls on, and learn which jitter and loss numbers mean trouble.
Your internet is fast and your calls are still bad. Zoom freezes for two seconds at a time, Teams drops to a slideshow, your voice turns robotic mid-sentence. You run a speed test and it says 500 Mbps. Everyone concludes the network is fine.
The network is not fine. The two numbers that prove it, jitter and packet loss, don’t appear on a speed test at all.
The short answer
Speed tests measure average throughput over TCP. Calls run on UDP and suffer from jitter (variation in packet arrival time) and packet loss. Run an iPerf3 UDP test at the call’s bitrate (3 to 5 Mbps) from the device you take calls on: jitter under 30 ms with loss under 1% supports stable video. Throughput can be excellent while both of these are far out of range.
Why a fast connection still drops calls
A file download rides TCP. When a packet gets lost, TCP retransmits it, and the only visible symptom is a slightly lower average speed. The transfer arrives complete, every time, and a speed test built on the same mechanics reports a healthy number.
A call cannot wait for a retransmission. By the time the lost packet could be resent, the moment for that slice of audio has passed. So real-time apps ride UDP, accept the loss, and try to conceal the gaps: codecs interpolate missing audio, video freezes on the last good frame. Concealment works up to a point, and past that point you get the robot voice.
Three numbers decide whether a link can carry a call:
- Latency: how long a packet takes to cross the network.
- Jitter: how much that time varies from packet to packet. The receiver buffers against jitter, and every extra millisecond of buffer is added delay in the conversation.
- Packet loss: the share of packets that never arrive.
The classic targets for voice, published by Cisco years ago and still the working standard: one-way latency under 150 ms, jitter under 30 ms, loss under 1%. Video conferencing has close to the same envelope with a higher bitrate.
What an iPerf3 UDP test reports
In UDP mode, the sender pushes datagrams at a rate you choose. The receiver timestamps each arrival and reports two things: jitter, computed as a smoothed running variation of arrival intervals (the RFC 3550 method that RTP itself uses), and lost/total datagrams. That is the pair of numbers a call depends on, measured on your own network with no internet variables mixed in.
One detail matters before you start: the statistics describe the receiving end of the flow. A download test (server to phone) tells you how a call would arrive at your phone; an upload test tells you how your voice leaves it. Uplink and downlink misbehave independently, so run both.
The test, step by step
- Start a server on a wired machine. A Mac in Server mode, plugged into Ethernet, is ideal. Note the IP and port. Keeping the server on a cable pins one end of the path, so whatever you measure happened on the wireless side.
- Take the phone to where the calls happen. The kitchen table, the home office, the meeting room. Testing from the couch next to the router answers a different question.
- Switch the test type to UDP. In the app this is one toggle in Pro mode.
- Set the UDP bitrate to the call’s rate. 3 to 5 Mbps mirrors HD video conferencing; 100 kbps mirrors a voice-only call. The default 1 Mbps sits in between and works as a first pass.
- Run for 60 seconds. A 10-second test can miss the burst of loss that ruins one moment per meeting. Longer windows catch the pattern.
- Run download, then upload, and save both. The history view keeps them side by side.
Test at the call's bitrate, not the line rate
A UDP test at 900 Mbps answers “how much UDP can this path carry” and will report loss on a link that carries a 4 Mbps call without dropping a frame. For call diagnosis, match the app’s rate. For a capacity measurement, run a second test at a high rate and note where loss begins; that ceiling is useful for a different set of problems.
Reading the numbers
Jitter:
- Under 10 ms: clean. Nothing to fix on this axis.
- 10 to 30 ms: workable. Codecs and jitter buffers conceal it, at the cost of a little added delay.
- Over 30 ms: audible and visible. Conversations start talking over each other because the buffer delay stacks onto the latency.
Packet loss:
- Under 0.5%: fine for anything.
- 0.5 to 1%: occasional artifacts, tolerable for most meetings.
- Over 1%: robot voice, smeared video, visible freezes.
- Over 3%: calls disconnect.
The pattern carries as much information as the totals. Steady low-grade loss across the whole run points to congestion: a saturated uplink or a busy channel. Clean stretches broken by bursts of loss point to interference, a DFS channel change, or the phone roaming between access points mid-call.
The usual culprits, in order
- The phone is on 2.4 GHz. The band is crowded and jittery in any apartment building. Force the call device onto 5 or 6 GHz and re-test.
- A saturated uplink. Cloud photo sync, a backup job, someone streaming: home connections have narrow upload lanes, and your outgoing voice competes with all of it. Loss that appears only in the upload test is the tell. Rate-limit the backups or enable QoS.
- A congested channel. High jitter at all hours that worsens in the evening. Change the channel or move to a cleaner band.
- Coverage. If the meeting room sits at the edge of Wi-Fi range, jitter and loss climb together. That case is a dead-zone problem, and the fix is placement or another access point, not QoS.
- A VPN in the path. Encapsulation adds overhead and a detour adds latency. Test with the VPN on and off to see what it costs.
Bottom line
“The internet is fast but calls are bad” is a measurable condition with a short differential diagnosis. TCP speed tests can’t see it, because the two numbers that matter, jitter and packet loss, only show up when something sends UDP at a controlled rate and counts what arrives. That is a one-toggle test in iPerf3: UDP mode, the call’s bitrate, 60 seconds, both directions. Run it in the room where the calls happen and the vague complaint turns into a number with a known fix.