Latency, jitter and packet loss: what Mbps hides

What the three numbers actually are

Latency is delay. A speed test reports it as a round trip: your device sends a packet, something far away sends one back, and the stopwatch runs the whole way. Jitter is how much that delay wobbles from one packet to the next. Packet loss is the share of packets that never arrive at all.

The reason the three are usually discussed together is that they are not three independent faults. They are one delay budget being spent in different places, and two of them convert into each other.

Here is the conversion, and it is the part almost no guide explains. Real-time audio cannot be played back the instant a packet lands, because packets do not land evenly. So the receiving end runs a de-jitter buffer: it collects packets, puts them back in order, and holds them briefly so playback runs smoothly. ITU-T G.114 says the buffer’s contribution to one-way delay “may be as low as one half of the peak buffer size”, and the planning example it borrows from ITU-T Y.1541 is a buffer built to absorb 50 ms of packet delay variation, which “will introduce 25 ms additional delay, on average”. That is jitter turning into latency.

Then the second conversion. If a packet shows up later than the buffer can wait, G.114 is blunt about what happens: the packet “arrives too late” with respect to its intended play-out time and “will be discarded”, so “the speech carried in this packet is lost for the decoding process”. Nothing dropped it on the network. Your line reports zero loss. The audio is gone anyway. That is jitter turning into packet loss.

This is why symptoms map cleanly onto causes. Robotic, watery voices and missing syllables are the buffer failing: jitter or loss. People talking over each other, and that walkie-talkie rhythm where nobody knows whose turn it is, is delay — Microsoft describes exactly that trio, with jitter making packets arrive at different speeds that “cause a speaker’s voice to sound robotic”, loss “resulting in missed syllables and words”, and round-trip time causing “a walkie-talkie effect”. Video that freezes then jumps to catch up is loss or starvation in the video stream, which is why Microsoft says that “when bandwidth is insufficient, Teams prioritizes audio quality over video quality”.

The thresholds you have read are mostly not real

Search this topic and you will get the same triad on page after page: latency under 150 ms, jitter under 30 ms, packet loss under 1%, frequently attributed to Zoom, or to “ITU standards,” with no link. Both attributions fall apart when you open the documents.

Zoom’s system requirements page does not publish any of it. It gives bandwidth and nothing else: 600 kbps up and down for high-quality one-to-one video, 1.2 Mbps for 720p HD, 3.8 Mbps up and 3.0 Mbps down for 1080p HD, and 60–80 kbps for VoIP audio. The words “latency”, “jitter” and “packet loss” do not appear on it at all. Google’s Meet network guidance is the same: 1 Mbps outbound and 1.3 Mbps inbound per participant for video in large organizations, 12 kbps out and 18 kbps in for audio only, and not one numeric impairment threshold anywhere on the page. Microsoft publishes bandwidth on its network-prep page too, with one-to-one audio at 10/10 kbps minimum and 58/58 recommended, one-to-one video at 150/150 minimum and 1,500/1,500 recommended, and a note that Teams “can deliver HD video quality in under 1.5 Mbps”.

The ITU attribution is subtler, and worth getting right. G.114 is a real Recommendation — the ITU catalog still lists the 05/2003 revision as in force, together with a 2009 amendment adding an appendix on delay variation — and it does contain numbers, but that revision explicitly reorganized how they are used. It says that regardless of the type of application it is recommended “to not exceed a one-way delay of 400 ms for general network planning”, and that although “a few applications may be slightly affected by end-to-end … delays of less than 150 ms, if delays can be kept below this figure, most applications, both speech and non-speech, will experience essentially transparent interactivity”. It also says highly interactive tasks “may be affected by delays below 100 ms”, and that the older habit of treating network delay and application-level “mouth-to-ear” delay in parallel “led to confusion in how ITU-T Rec. G.114 should be applied” — which is why it now points at the G.107 E-model for judging speech quality rather than at a single threshold.

Two things follow. First, G.114’s 150 ms figure is one-way and mouth-to-ear: it includes the microphone, the codec, packetization, the jitter buffer and the loudspeaker, not just network transit, while its 400 ms limit is a network-planning figure measured “UNI to UNI”. Your speed test’s “ping” is a round trip across the network only. Comparing “150 ms ping” to “G.114’s 150 ms” compares two different measurements. Second, the tidy three-band table of acceptable / degraded / unacceptable that gets cited to G.114 is not in the current text, which instead gives a single E-model curve of transmission rating against mouth-to-ear delay.

Of the three, the one that does publish hard numbers is Microsoft, in the Teams Call Quality Dashboard — and they are looser than the folklore, not tighter.

The 1% packet-loss number is the one piece of the folklore that survives scrutiny, and its real source is the FCC, not a video platform. In its Thirteenth Measuring Broadband America fixed report the Commission bands consumer packet loss at up to 0.4%, 0.4–1%, and over 1%, and says “the 1% standard for packet loss is commonly accepted as the point at which highly interactive applications such as VoIP experience significant degradation in quality”. It also supplies the correction nobody quotes: “packet loss of a few tenths of a percent, for example, is common and is unlikely to affect significantly the perceived quality of most Internet applications”, and while “most SLAs support 0.1% to 0.3% packet loss guarantees”, those are enterprise agreements — “consumer offerings typically are not subject to SLAs”.

What your access technology floors you at

Some of your latency is not negotiable. It is set by physics and by the technology at your address, and no router changes it.

Those FCC figures come from measurements taken in September and October 2022 and are the idle case. Notice how much room there is under a 500 ms round-trip threshold at every wired technology. If your calls break, idle latency is almost certainly not why.

How to measure it, and why one speed test is not enough

The IETF’s IP Performance Measurement working group puts the problem in one sentence: most current latency tests report the round-trip time when the network is otherwise idle, which is “not a good predictor of how a network will behave when it is actively being used for normal data transfer”. The same draft rejects the resignation most people have absorbed — everyone “knows” it is “normal” for a video conference to have problems when somebody else at home is watching a 4K movie, and the draft answers that “there is no technical reason for this to be the case”. The FCC reached the same conclusion from the other direction and added latency under load to its report, finding that it “generally is significantly higher than idle latency, with a more pronounced difference for DSL subscribers”.

So measure it this way, in this order:

1. Take a baseline. Run a speed test with nothing else using the connection and write down the latency and, if the tool shows it, the jitter figure. This is the number that means the least, but you need it for comparison.
2. Run the same test under load. Start a large file upload to a cloud drive, leave it running, and rerun the test. If latency climbs from 20 ms to several hundred, you have found your problem: the link buffers up under load and your call packets queue behind bulk traffic. A responsiveness test reports this as RPM, round-trips per minute — “60,000 divided by the round-trip time in milliseconds”, so higher is better.
3. Test wired, then wireless. Repeat both tests on Ethernet if you can, then on Wi-Fi in the room you work in. A gap between them is a home problem, not a provider problem.
4. Run it long, not once. Jitter and loss are behaviors over time. A single 10-second test can miss the 4 p.m. congestion that ruins your standup. Test at the hour your calls actually break.
5. Read the meeting app’s own statistics. Most conferencing apps expose a per-call quality panel showing round-trip time, jitter and loss for your actual media stream, which is the traffic being graded, not a speed test’s traffic to an unrelated server. Menu names and locations vary by app and version, so look for a call health, statistics or connection quality item.

Which of it you can fix

Inside your home, the fixable causes are ordered by likelihood times cost to check. Wi-Fi first: Microsoft states that “Wi-Fi deployments don’t typically take into consideration the network requirements for VoIP services and are often a source of poor quality”, and its network guidance points at access point placement, the crowded 2.4 GHz range versus 5 GHz, and Wi-Fi Multimedia prioritization. Uplink second: one background cloud backup can saturate a home upstream and leave your call packets queued behind it.

VPN third, and both vendors that discuss it agree. Microsoft recommends split-tunnel VPN specifically because traffic hairpinned through a VPN device “might be routed to a service front door location that is further away from the end user, introducing extra latency and jitter”. Google says the same of Meet — “VPNs add latency and can cause Meet to reduce video and audio quality” — and tells administrators to “enable split tunneling for your VPN”.

What you cannot fix from inside is the access technology’s floor, the distance to the far end, and congestion in your provider’s network. If your loaded latency stays clean on Ethernet and your calls still break, that is the conversation to open with your provider: “My idle latency is X, my latency under downstream load is Y, and I am seeing Z% packet loss on a wired connection. Can you check for congestion or errors on my line?” Numbers from a wired test are much harder to deflect than “my internet is bad.”

Caveats, confidence and limits

Every number on this page came from the document named beside it in the source panel below, and the dates there are the dates those documents were opened. Four limits are worth stating outright.