Introduction
People often use 'bandwidth' and 'speed' interchangeably, but network performance is actually described by several distinct metrics: bandwidth, throughput, latency, jitter, and packet loss. Each measures a different property of the connection, and a network can be excellent on one metric while poor on another — for example, a satellite link can have huge bandwidth but terrible latency. Knowing which metric is actually causing a problem is essential to fixing it correctly.
Cricket analogy: A stadium's floodlight capacity (bandwidth) differs from how brightly it actually performs during a rain-affected match (throughput), and commentators must diagnose whether a broadcast delay is due to satellite lag (latency) or a shaky camera feed (jitter), not just call it all 'bad signal'.
Explanation
Bandwidth is the theoretical maximum capacity of a link, usually expressed in bits per second (e.g., a '100 Mbps' connection). It describes how much data the medium could carry under ideal conditions. Throughput is the actual rate of data successfully transferred over that link in practice, which is always less than or equal to bandwidth once you account for protocol overhead, congestion, retransmissions, and contention with other traffic. Latency is the time it takes for a single piece of data to travel from sender to receiver (often measured as one-way delay or round-trip time), caused by propagation delay, transmission delay, queuing delay, and processing delay. Jitter is the variation in latency over time — if consecutive packets arrive with delays of 20ms, 21ms, 45ms, 22ms, that fluctuation is jitter, and it is especially damaging to real-time applications like voice and video calls because it disrupts smooth playback even when average latency looks fine. Packet loss is the percentage of packets that never arrive at all, typically caused by congestion, faulty hardware, or wireless interference, and it forces retransmissions (in TCP) or visible glitches (in UDP-based media).
Cricket analogy: A stadium's floodlight rated wattage is bandwidth, but the actual lux hitting the pitch during play is throughput; the time between a bowler's release and ball impact is latency, uneven over after over is jitter, and dropped catches are like packet loss forcing a re-bowl in TCP terms.
Example
# Illustrative scenario: bandwidth vs throughput vs latency
#
# Link bandwidth: 100 Mbps (theoretical capacity)
# Measured throughput during a large file transfer: 62 Mbps
# (lower than bandwidth due to TCP overhead, other traffic, and congestion)
#
# Bandwidth-Delay Product (BDP) example:
# BDP = bandwidth * round-trip time
# bandwidth = 100 Mbps = 100_000_000 bits/sec
# RTT = 80 ms = 0.080 sec
# BDP = 100_000_000 * 0.080 = 8_000_000 bits = 1,000,000 bytes (~1 MB)
#
# This means: to fully utilize a 100 Mbps link with 80ms RTT,
# roughly 1 MB of data must be 'in flight' (unacknowledged) at any
# given time -- if TCP's send/receive window is smaller than this,
# throughput will fall well below the 100 Mbps bandwidth ceiling,
# even with zero packet loss.
bandwidth_bps = 100_000_000
rtt_seconds = 0.080
bdp_bits = bandwidth_bps * rtt_seconds
bdp_bytes = bdp_bits / 8
print(f"Bandwidth-Delay Product: {bdp_bytes:,.0f} bytes")Analysis
The bandwidth-delay product (BDP) example above shows why a high-bandwidth link can still deliver disappointing throughput: if the TCP window size is smaller than the BDP, the sender runs out of 'credit' to keep transmitting and must wait for acknowledgments, leaving the link underutilized regardless of its raw capacity. This is a common real-world scenario on long-distance, high-bandwidth links (like transcontinental fiber), sometimes called the 'long fat network' problem. Separately, latency and jitter matter most for real-time, interactive traffic — a video call can tolerate moderate constant latency far better than it tolerates jitter, because jitter causes audio/video stutter even when the connection is otherwise healthy. Packet loss compounds these effects: in TCP, lost packets trigger congestion control to shrink the send window, further reducing throughput even if bandwidth is technically available.
Cricket analogy: A team with a huge run-rate cushion but a slow over-rate still gets penalized because they run out of overs to convert that cushion into a score, just as a high-bandwidth link with too small a TCP window can't convert its capacity into throughput.
Key Takeaways
- Bandwidth is theoretical capacity; throughput is what is actually achieved and is always <= bandwidth.
- Latency is the delay for data to travel one-way or round-trip; jitter is the variation in that latency over time.
- Packet loss forces retransmissions in TCP and visible glitches in real-time UDP traffic.
- The bandwidth-delay product explains why high bandwidth alone doesn't guarantee high throughput on high-latency links.
Practice what you learned
1. What is the key difference between bandwidth and throughput?
2. Which metric specifically describes the variation in packet delay over time?
3. Why can a link with very high bandwidth still deliver low throughput?
4. In real-time voice or video calls, why is jitter often more disruptive than a moderate constant latency?
Was this page helpful?
You May Also Like
Network Troubleshooting Tools
Learn how ping, traceroute, netstat/ss, and nslookup/dig work under the hood to diagnose connectivity, routing, and DNS issues.
TCP Flow and Congestion Control
Distinguish TCP's receiver-driven flow control from its network-driven congestion control mechanisms.
TCP vs UDP
Compare TCP and UDP across reliability, ordering, connection state, overhead, and typical use cases.
Transport Layer Basics
Learn how the transport layer provides process-to-process delivery between applications running on different hosts.