Bandwidth is capacity. Latency is delay. Throughput is achieved rate.
These metrics describe different properties of a network. A link can have enormous capacity and still feel slow during interactive work because each request must wait for a long round trip. Conversely, a nearby low-capacity link can respond quickly but move a large file slowly.
Try the AP Networking TCP and UDP Transport Troubleshooting Practice Test when a high link rate tempts you to assume an application must be fast. The worked bandwidth-delay calculation and window/queue scenarios identify why nominal capacity can coexist with poor measured throughput.
AP exam rule
Do not translate “fast network” into one number. Ask whether the task needs low delay, high transfer rate, consistent timing, or low loss.
Total latency is built from multiple delay components
Propagation
Time for the signal to physically travel through the medium. Distance matters even on an uncongested fast link.
Transmission
Time required to place all packet bits onto a link. Packet size and link rate matter.
Processing
Time devices spend examining headers, applying policy, routing, encrypting, or otherwise handling traffic.
Queueing
Time packets wait behind other packets. This can vary dramatically with load.
Transmission delay falls as link rate rises
For a packet of 1,500 bytes, first convert to bits: 1,500 × 8 = 12,000 bits.
The gigabit link places the packet onto the medium much faster. But this calculation does not erase propagation, processing, or queueing delay elsewhere in the path.
More bandwidth cannot repeal physical distance
A long geographic path has a propagation floor. Upgrading a 1 Gbps circuit to 10 Gbps may improve capacity and transmission time without meaningfully shortening the distance signals travel.
Ping commonly reports round-trip time, not one-way latency
An ICMP echo request travels to the destination and the reply returns. The measured time therefore includes both directions plus endpoint/path processing. Dividing RTT by two gives only a rough estimate of one-way delay because forward and return paths can differ.
See ICMP and Ping Explained for deeper interpretation.
Bandwidth is the ceiling; throughput is what you actually achieve
A 1 Gbps interface does not guarantee a 1 Gbps file transfer. The end-to-end rate can be constrained by a slower link, congestion, loss/retransmission, server performance, storage speed, protocol overhead, wireless conditions, or transport behavior.
An end-to-end path is constrained by its weakest relevant stage
Ignoring overhead and other constraints, the 100 Mbps segment prevents the path from delivering a sustained 1 Gbps end-to-end transfer. Upgrading a different already-gigabit segment would not remove that bottleneck.
Latency can explode under load even while throughput looks impressive
When traffic arrives faster than an outgoing link can transmit it, packets wait in a queue. Large buffers can prevent immediate drops but create long delays. This is why a connection can still report a high download rate while voice, gaming, SSH, or remote desktop becomes unpleasant.
| State | Idle RTT | Loaded RTT | Throughput | Interpretation |
|---|---|---|---|---|
| Idle | 18 ms | — | — | Low baseline delay |
| Large upload active | — | 240 ms | High | Queueing under load is strongly suggested |
| Upload stops | 19 ms | — | — | Delay returns near baseline |
Swipe horizontally to inspect the loaded-latency evidence.
Average latency can hide unstable packet timing
Real-time voice and interactive traffic can be harmed by changing delay because packets do not arrive at consistent intervals. Jitter buffers can smooth some variation, but excessive variation can still degrade experience.
Loss can reduce throughput even when bandwidth is plentiful
Lost packets may need retransmission, and reliable transports such as TCP can respond to loss by reducing sending behavior. The result can be lower achieved throughput without any change to the link's advertised bandwidth.
The same network can be excellent for downloads and frustrating for conversation-like applications
Interactive workload
Remote desktop, gaming, SSH, and request/response workflows are sensitive to delay because progress may depend on repeated back-and-forth exchanges.
Bulk workload
Large downloads can keep substantial data in flight. With adequate windows and low loss, they can use a high-bandwidth path despite a longer RTT.
Round trips matter when acknowledgments and control loops govern sending
TCP performance is influenced by RTT, loss, congestion control, and the amount of data permitted in flight. On a high-bandwidth, high-latency path, a sender needs enough outstanding data to keep the path busy instead of repeatedly waiting with unused capacity.
This means roughly 1.25 MB of data could be “in flight” on that simplified 100 Mbps, 100 ms path.
A faster long-distance path needs more data in flight to stay full
| Bandwidth | RTT | Approx. BDP | Interpretation |
|---|---|---|---|
| 10 Mbps | 20 ms | 25 KB | Relatively little data needed in flight |
| 100 Mbps | 100 ms | 1.25 MB | More outstanding data required |
| 1 Gbps | 100 ms | 12.5 MB | High-capacity long-RTT path needs a much larger flight size |
Swipe horizontally to compare bandwidth-delay products.
Small packets still wait behind large packets on a busy slower link
Suppose a voice packet reaches an outbound interface just after a large data packet begins transmission. Even if the voice packet is tiny, it cannot be transmitted on that serial link until the current frame finishes. Queueing and scheduling can add further delay.
This helps explain why slower links can make packet scheduling and queueing much more visible to interactive traffic.
Read several metrics together before recommending an upgrade
One changed measurement should change the diagnosis
| Original evidence | Changed fact | Reasoning shift |
|---|---|---|
| 180 ms RTT; remote desktop delayed | Bandwidth doubles; RTT stays 180 ms | Capacity improved, but interaction-delay cause remains |
| 10 Mbps transfer on 1 Gbps LAN | One path segment negotiates at 10 Mbps | Physical/link bottleneck becomes strong |
| Loaded RTT jumps to 250 ms | Queue-management change keeps it near 25 ms | Queueing explanation gains support |
| Throughput is poor | Loss rises to 8% | Loss/retransmission becomes an important factor |
| Voice sounds uneven | Average RTT stays low but samples vary widely | Jitter becomes more relevant than average latency alone |
Swipe horizontally to practice changed-fact reasoning.
Match the tool to the metric you actually need
| Observation/test | Useful for | Does NOT by itself prove |
|---|---|---|
| Ping RTT | Round-trip response timing/loss samples | Bandwidth or application throughput |
| Throughput test | Achieved transfer rate during the test | Low latency or low jitter |
| Repeated RTT samples | Delay variation and possible loss | Exact bottleneck location |
| Interface link speed | Negotiated/nominal local link rate | End-to-end application rate |
| RTT while load is generated | Queueing/loaded-latency behavior | That every delay increase has one specific cause |
Swipe horizontally to compare measurement limits.
Correct these performance misconceptions
- “More bandwidth always lowers ping.” Not necessarily; propagation and other delay components can remain.
- “Ping measures speed.” Ping primarily reports RTT/loss behavior for probes, not transfer capacity.
- “1 Gbps interface means 1 Gbps download.” End-to-end throughput can be limited elsewhere.
- “No packet drops means no congestion problem.” Deep queues can create severe delay before drops become obvious.
- “Average latency tells the whole story.” Jitter can make timing unstable even with an acceptable average.
- “High bandwidth makes distance irrelevant.” Physical propagation remains.
- “Good speed test means real-time apps must be good.” Interactive performance also depends heavily on delay, jitter, and loss.
Use TASK → METRIC → BASELINE → LOAD → BOTTLENECK → VERIFY
24 interactive latency and bandwidth reasoning cards
These cards test metric selection, calculations, evidence limits, congestion, jitter, and TCP reasoning.