> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/concepts/latency-jitter-packet-loss.md).

# Latency, Jitter & Packet Loss

Your speed test says 500 Mbps. Your video call still breaks up. How can both be true?

Because speed is only one dimension of a connection, and often not the one that matters. Three other numbers usually explain the difference.

## The three metrics in plain words

Imagine posting a letter and waiting for a reply.

**Latency** is how long the round trip takes. You send, they answer, the answer arrives. Measured in milliseconds (ms). This is what a ping test reports. Low latency means the connection feels responsive.

**Jitter** is how much that round-trip time varies. If replies come back in 20 ms, then 22 ms, then 21 ms, the delivery is dependable. If they come back in 20 ms, then 90 ms, then 15 ms, something is inconsistent — even though the average looks fine. Jitter is the size of that variation, also in milliseconds.

**Packet loss** is letters that never arrive at all. Data travels as small pieces called packets, and some fraction may be dropped along the way. Measured as a percentage. Lost pieces are usually re-sent, which costs time; for live audio and video there is no time to re-send, so the gap is simply audible.

And **bandwidth**, the number a speed test headlines, is how much can be carried at once — how wide the road is, not how quickly one car crosses it.

| Metric      | Question it answers              | Unit | Ruined experience                         |
| ----------- | -------------------------------- | ---- | ----------------------------------------- |
| Latency     | How long until I get a response? | ms   | Slow-feeling everything; unplayable games |
| Jitter      | How consistent is the delay?     | ms   | Choppy, robotic voice calls               |
| Packet loss | How much never arrives?          | %    | Stutters, freezes, dropouts               |
| Bandwidth   | How much fits at once?           | Mbps | Slow downloads; low-quality video         |

## Why latency is not speed

This is the single most useful idea on the page.

Bandwidth and latency are independent. A satellite link can carry enormous bandwidth while every round trip takes half a second, because the signal physically travels to orbit and back. A modest home connection to a nearby server can have very low latency and modest bandwidth.

Latency is set mostly by **distance and the number of hops**, not by how much you pay. Light in fibre covers roughly 200 kilometres per millisecond, and every router, every intermediate network, every queue adds a little more. A round trip across an ocean cannot be faster than physics allows, no matter what plan you buy.

So upgrading to a faster plan will not fix a laggy game on a distant server. It will make large downloads finish sooner. Those are different problems.

## What counts as good

Be careful with any single set of thresholds, including these. What is acceptable depends heavily on what you are doing, how far away the other end is, and what connection technology you use. A 60 ms round trip to a server on another continent is excellent; the same 60 ms to a server in your own city suggests a problem. Mobile and satellite connections operate in entirely different ranges from fibre.

With that caveat, rough guidance for a fixed home connection to a reasonably nearby server:

|             | Good          | Usable      | Problematic    |
| ----------- | ------------- | ----------- | -------------- |
| Latency     | under \~30 ms | \~30–100 ms | above \~150 ms |
| Jitter      | under \~10 ms | \~10–30 ms  | above \~30 ms  |
| Packet loss | 0%            | under \~1%  | above \~2–3%   |

Two things matter more than the exact numbers.

First, **compare against yourself**. A connection that normally shows 18 ms and today shows 90 ms has a problem, whatever a table says. Your own baseline is the most informative benchmark you have.

Second, **measure under load**. Latency measured on an idle connection can look excellent and then collapse when someone starts an upload — a symptom called bufferbloat, where oversized queues in network equipment delay everything behind a big transfer. Latency measured while the connection is busy is much closer to what you actually experience.

## Where the delay actually comes from

A round trip is not one delay but several, added together.

* **Distance.** The unavoidable part. Signals travel at a finite speed, and real fibre routes are longer than the straight line on a map.
* **Hops.** Every router along the way takes a moment to inspect and forward each packet. A path with thirty hops costs more than a path with eight.
* **Queuing.** When a link is busier than it can serve, packets wait in a queue. This is the largest and most variable contributor on a congested connection, and the main source of jitter.
* **The last mile.** The technology connecting your building matters. Fibre adds very little; older copper and cable technologies add more; mobile and satellite add considerably more.
* **The far end.** The server itself needs time to think before replying. A slow application can look exactly like a slow network.

Only the first of these is fixed. Everything else can be improved — which is why a connection that is slow today may be fine tomorrow without anything changing on your side.

## What each one ruins

**Gaming is destroyed by latency, then by packet loss.** Competitive games need your input to reach the server and the result to come back before the moment passes. Bandwidth is almost irrelevant — games send tiny amounts of data. This is why a player on a modest connection close to the server beats a player on a very fast connection far away. Packet loss shows up as rubber-banding, where things snap back to where they were.

**Voice and video calls are destroyed by jitter, then by packet loss.** Audio must play out at a steady rate. Applications hold a small buffer to absorb variation, but if arrivals are erratic enough the buffer runs dry and you get the familiar robotic, chopped-up voice. Lost packets cannot be re-sent in time, so they become brief silences. Calls need surprisingly little bandwidth, which is why they fail on connections that test as fast. See [What Is WebRTC?](/knowledge-base/concepts/what-is-webrtc.md).

**Streaming video is destroyed by bandwidth, and only mildly bothered by latency.** A video player buffers several seconds ahead, so it absorbs jitter and moderate latency easily. What it cannot absorb is insufficient bandwidth: it drops the quality, and if things get worse it stalls to rebuffer. A few seconds of extra start-up delay is a latency symptom; a picture that goes soft mid-scene is a bandwidth symptom.

**Ordinary web browsing is mostly a latency problem.** A page pulls in dozens of separate resources, each needing a request and a response. Latency is paid repeatedly, so a high-latency connection feels sluggish even when raw bandwidth is plentiful. Beyond roughly 50 Mbps, extra bandwidth barely changes how fast pages feel.

## Common misconceptions

**"More Mbps fixes lag."** It does not. Lag is latency. Bandwidth and latency are separate properties of the path.

**"Zero packet loss is required."** Occasional loss is normal and invisible. Consistent loss above a percent or two is what degrades things — and loss that appears only at one hop in a traceroute is often that router deprioritising its own replies, not real loss affecting your traffic.

**"A single test tells me my connection quality."** One measurement is a snapshot of one moment on one path. Repeat it, at different times, to different places, before concluding anything.

**"High ping to one site means my connection is bad."** It may mean that one site is far away, or that one route is congested. Testing several destinations separates a local problem from a path problem.

{% hint style="info" %}
**See it yourself on MyIP**

The [Speed Test](/knowledge-base/network-tests/speed-test.md) reports more than download and upload figures: it also shows latency, jitter, and latency measured *while the connection is loaded* — then translates all of it into quality scores for video streaming, gaming, and video chatting. That last row is the point of this page in a single glance.

To see how these numbers change with distance, the [Global Latency Test](/knowledge-base/network-tests/global-latency-test.md) pings your address from probes around the world. And when a specific route looks bad, the [MTR Test](/knowledge-base/network-tests/mtr-test.md) breaks the path into hops and reports latency and loss at each one, so you can see where the damage begins.
{% endhint %}

## Related concepts

* [What Is an ASN?](/knowledge-base/concepts/what-is-an-asn.md) — why the route between networks decides your latency
* [What Is WebRTC?](/knowledge-base/concepts/what-is-webrtc.md) — why calls are so sensitive to jitter
* [Public, Private & CGNAT Addresses](/knowledge-base/concepts/public-private-cgnat.md) — extra hops between you and the internet
* [Why Is My Internet Slow?](/knowledge-base/diagnose/why-is-my-internet-slow.md) — a step-by-step diagnosis


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/concepts/latency-jitter-packet-loss.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.