# Bandwidth is not speed

Bandwidth is the capacity of a link; latency is how long a packet takes; jitter is the variation in that delay; loss is the share of packets that never arrive. A link can be wide and still feel slow if the round trip, the variation or the loss is bad. Choose the metric that matches the application.

- Bandwidth is capacity; latency, jitter and loss decide how an interactive application feels.

- Jitter is the variation in delay; a stable path can feel better than one whose delay swings widely.

- Packet loss is retransmitted for data, which adds delay, and concealed for real-time media, which shows up as a glitch.

- One stream's throughput is limited by the TCP window and the round-trip time, not only by the link rate.

- ITU-T G.114 places 150 ms one-way at the top of the band that suits most voice users.

## Bandwidth is the pipe

Bandwidth is the width of the pipe: how many bits can cross in a second under the conditions of the link. Latency is the trip: how long one packet takes to reach the other end and, for a round trip, to come back. They are different measurements, and one does not imply the other.
A 100 Mbps link can feel slow on a video call because the call does not need 100 Mbps. It needs a round trip short enough for conversation, jitter low enough for the audio buffer and loss low enough that the codec does not conceal a gap. The headline rate does not describe any of those.
Bandwidth matters for bulk transfer, backup, video upload and many devices at once. It also matters for the congestion that produces latency and loss. But when a person says the link feels slow, ask which application and which of the four metrics that application depends on.

### The round trip on a log scale

Marks at 5, 40, 130 and 400 ms are guidance bands, not a target for a route. The 130 ms mark is the great-circle fiber floor for a Mexico City–Shanghai pair at a path factor of 1.0; the tool applies the scenario's 1.5 factor.

Alt: A logarithmic scale from 1 to 1000 ms with marks at 5, 40, 130 and 400 ms, labeled same metro, regional, intercontinental and queues or a long path.

The scale runs from 1 ms to 1000 ms. A same-metro path sits near the left, a regional path in the tens of milliseconds, and an intercontinental path in the low hundreds. The marks describe distance and queues, not a service target. A measured round trip also includes the equipment and the route, so it is higher than the fiber floor.

| Item | Value | Note |
| --- | --- | --- |
| 5 ms |  | Same metro |
| 40 ms |  | Regional path |
| 130 ms |  | Intercontinental path |
| 400 ms |  | Queues or a long path |

Source: Fiber latency floor and TCP throughput calculator: physics note (https://unicomam.com/en/tools/fiber-latency/)

## Jitter and loss decide the experience

Jitter is the variation in delay from packet to packet. A stream can have a good average and still arrive unevenly. Real-time media carry a buffer to absorb the variation; when the spread exceeds the buffer, the audio clips or the video freezes.
A stable path is easier to use than one whose delay swings widely. The average may look similar. The stable path lets the application plan; the swinging path forces it to wait for the slow tail or to discard packets it cannot use.
Loss is the third signal. Data applications retransmit, which adds a round trip and reduces throughput. Real-time media conceal the missing packet, which shows up as a glitch. A loss rate that looks small on average can cluster in bursts and hurt more than the average suggests.

### An illustrative delay distribution

An illustrative distribution: p50 at 40 ms and p95 at 180 ms. The gap between them is the variation the application has to absorb. The numbers are illustrative, not a measurement of a network.

Alt: A strip from 0 to about 216 ms with a typical packet at 40 ms and a slow tail at 180 ms, showing a variation of 140 ms.

Half the packets arrive at or below 40 ms and 95 percent at or below 180 ms. The 140 ms gap is the spread the application must buffer or discard. A different network or time of day would produce a different distribution; the shape, not the exact number, is the lesson.

| Item | Value | Note |
| --- | --- | --- |
| p50 | 40 ms | Typical packet |
| p95 | 180 ms | Slow tail |
| p95 − p50 | 140 ms | Variation |

Source: Illustrative model; ITU-T Y.1540 and Y.1541 define delay variation (https://www.itu.int/rec/T-REC-Y.1540/en)

### Typical thresholds, by application

| Application | What to measure | Typical guidance |
| --- | --- | --- |
| Interactive voice and video | One-way delay, RTT, jitter, loss | G.114 treats 0–150 ms one-way as acceptable for most voice users, 150–400 ms as transitional and above 400 ms as generally unacceptable. |
| Remote control and gaming | RTT and loss | Responsiveness falls as RTT rises. Measure the application's own round trips rather than a single ping. |
| Web and API transactions | RTT, TTFB, loss | Separate name lookup, connect, server time and the first byte. A fast link can still wait on the server. |
| Bulk transfer and backup | Throughput, loss, RTT | One stream is capped by the window and the RTT. More streams or a larger window can raise throughput. |

The table is teaching guidance, not a service target. Record the window and the route with every number.

## Measure over a window, from both ends

Measure from both ends and over a window. A single ping samples one packet at one moment; a call, a payment or a video stream uses many packets over minutes. Record the minimum, the median, the p95 and the loss over the busy hour, and keep the route and the destination with the numbers.
Measure the path the application uses. A public speed test measures a different destination and often a different route. A route test that reports only throughput cannot explain a call that stutters. Pair the throughput with RTT, jitter and loss, and separate the local leg from the international leg.
Report the window, the source, the destination and the time of day. A number without those four cannot be compared with another number. The [China connectivity explainer](/en/resources/learn/china-connectivity-options-latam/) shows how the path is built; the [roaming explainer](/en/resources/learn/home-routing-vs-local-breakout/) shows why the anchor changes the distance.

## What a useful route report contains

A route report should let a reader repeat the test. Record the source address, the destination address, the time window, the number of samples and the tool or method. A report that says only average RTT cannot be checked or compared.
Report the distribution, not only the average. The median describes the typical packet, the p95 describes the slow tail and the maximum shows the worst case. For a real-time application, the p95 and the loss matter more than the mean.
Separate the legs. A local access leg, an international transit leg and a destination leg fail for different reasons and have different owners. A single end-to-end number hides which leg to fix.
Keep the raw samples with the summary, and state the date. A route changes; a report without a date becomes a claim about a network that no longer exists.

The tool computes a physics floor for the scenario's city pair and path factor, not a measurement of any network.

[Open the tool](/en/tools/fiber-latency/?src=learn-bandwidth-latency-jitter-and-loss&scenario=mexico-shanghai&pathFactor=1.5)

### Check your understanding

**A 100 Mbps link feels slow on a video call: what do you measure, and over what window?**

Measure RTT, jitter and loss from the device to the call's destination over several minutes, including the busy hour. Throughput alone will not explain the call.

**Why can jitter be worse than a stable higher latency?**

A stable delay lets the application buffer once. A wide spread forces it to wait for the slow tail, and packets that arrive outside the buffer are discarded or concealed.

**Which metric would you put in a route test report?**

All four, with the window, source and destination. If the report must pick one headline, pair RTT with p95 jitter and loss, and keep throughput as context.

## FAQ

**Is bandwidth the same as speed?**

No. Bandwidth is capacity; speed is how the application feels, which depends on RTT, jitter and loss as well.

**What is a good latency?**

It depends on the application. ITU-T G.114 places 150 ms one-way at the top of the band that suits most voice users; interactive control and gaming usually want less.

**Does more bandwidth reduce latency?**

Not directly. More capacity can reduce queueing when the link is congested, but the distance and the route set the floor.

## Sources

- [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114/en) — Accessed: 2026-10-19
- [ITU-T Y.1541: Network performance objectives for IP-based services](https://www.itu.int/rec/T-REC-Y.1541/en) — Accessed: 2026-10-19
- [ITU-T Y.1540: Internet protocol data communication service - IP packet transfer and availability performance parameters](https://www.itu.int/rec/T-REC-Y.1540/en) — Accessed: 2026-10-19
- [IETF RFC 3393: IP packet delay variation metric for IP performance metrics](https://www.rfc-editor.org/rfc/rfc3393) — Accessed: 2026-10-19
- [Fiber latency floor and TCP throughput calculator: physics note](https://unicomam.com/en/tools/fiber-latency/) — Accessed: 2026-10-19

Updated: 2026-10-19