Bandwidth, latency, throughput, jitter

When users complain "the network is slow," they almost always mean one of four things and don't know which one. Getting these terms straight gives you the words to ask the right questions.

Bandwidth

The capacity of a link, measured in bits per second. It's the size of the pipe. A 1 Gbps link can carry, at most, one billion bits per second in each direction. It doesn't matter how few packets you send — bandwidth is the ceiling, not the floor.

| Common rates | Bits per second | |---|---| | 100 Mbps | 100,000,000 | | 1 Gbps | 1,000,000,000 | | 10 Gbps | 10,000,000,000 | | 100 Gbps | 100,000,000,000 |

Latency

The time for one bit (or one packet) to travel end to end. Usually measured in milliseconds. Latency adds up: every cable, every switch, every queue, every router contributes some.

| Source of latency | Typical value | |---|---| | Speed of light in fiber | ~5 µs per km | | Switch (cut-through) | <10 µs | | Switch (store-and-forward) | tens of µs | | Router (no queue) | hundreds of µs | | Router (deep queue) | milliseconds to seconds | | Satellite (geostationary) | 600+ ms |

A round trip from Stockholm to Sydney is around 280 ms over fiber — most of it is light-in-glass time, the rest is router hops. You cannot make light go faster, so you can't get latency below a hard physical floor.

Throughput

How much you actually achieve in practice, end to end. Always ≤ bandwidth. A 1 Gbps link might give you 940 Mbps of useful TCP throughput because of headers, retransmissions, and the receiver's TCP window.

If bandwidth is the size of the pipe, throughput is how much water actually came out.

The bandwidth-delay product

A subtle one. The amount of data "in flight" at any moment on a link equals bandwidth × latency. If you have a 1 Gbps transatlantic link with 80 ms RTT, the in-flight data is:

1,000,000,000 bps × 0.08 s = 80,000,000 bits = 10 MB

This is why TCP needs window scaling for long fat networks: the default 64 KB window keeps less than 1% of that pipe full. Throughput on a long-distance link is bounded by window / RTT, not by raw bandwidth.

Jitter

The variation in latency between packets. Voice and video care more about jitter than about average latency: a steady 100 ms is fine for a phone call; latency that bounces between 50 and 200 ms is awful. QoS exists largely to bound jitter for real-time traffic — we'll cover this in Track D.

Putting it together — common scenarios

| Complaint | Likely culprit | |---|---| | "Pages load slow" | Latency, or a congested upstream link saturating throughput | | "Big file copy is slow" | Throughput — check the bandwidth-delay product and TCP window | | "Voice calls cut out" | Jitter / packet loss, almost never raw bandwidth | | "Gaming lags" | Latency, sometimes jitter | | "Backup never finishes overnight" | Throughput on the WAN link, often saturated by daytime traffic |

What to remember

• Bandwidth = capacity (theoretical max).
• Throughput = actual achieved rate (always ≤ bandwidth).
• Latency = end-to-end delay. Bounded by physics.
• Jitter = variation in latency. Real-time apps hate it.
• "The network is slow" doesn't mean anything until you know which of these is the problem.