Bandwidth is not speed
Bandwidth is the pipe. Latency, jitter and loss decide how an application feels. Measure the one that matches the job.
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.
Key facts
- 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.
After this module you can
- Separate bandwidth from latency, jitter and loss.
- Choose the metric that matches an application's sensitivity.
- Design a measurement window and report a route test that can be compared.
On this page
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
40 ms
| Value | What it means |
|---|---|
| 5 ms | Same metro |
| 40 ms | Regional path |
| 130 ms | Intercontinental path |
| 400 ms | Queues or a long path |
Text description
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.
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
| Value | Zone | What it means |
|---|---|---|
| p50 | 40 ms | Typical packet |
| p95 | 180 ms | Slow tail |
| p95 − p50 | 140 ms | Variation |
Illustrative example; not a measurement of our network.
Text description
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.
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 shows how the path is built; the roaming explainer 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.
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.
Answers are revealed on request. Nothing is scored, stored or sent.
FAQ
Is bandwidth the same as speed?
What is a good latency?
Does more bandwidth reduce latency?
Sources
- ITU-T G.114: One-way transmission time
- ITU-T Y.1541: Network performance objectives for IP-based services
- ITU-T Y.1540: Internet protocol data communication service - IP packet transfer and availability performance parameters
- IETF RFC 3393: IP packet delay variation metric for IP performance metrics
- Fiber latency floor and TCP throughput calculator: physics note
Terms you'll meet
Related
- Permanent roaming, country by country
How long a foreign SIM may roam before it needs a local profile, for Brazil, Mexico and Colombia, with the decision path to the right product.
- SGP.32 for IoT devices
What SGP.32 changes for IoT fleets, which devices qualify, and why SGP.02 devices cannot be upgraded over the air.
- eUICC identifier (EID)
The eUICC identifier, separate from the subscription.
Put this to work
Tell us the traffic, the destination and the measurement you need; we reply with the next step.