Latency and bandwidth

The distinction, concretely

A 100 Gbit port between Amsterdam and Sydney still has a round trip of roughly 280 milliseconds, because light in fibre covers about 200 kilometres per millisecond and the cable does not go in a straight line. No amount of capacity changes that.

So:

• A page that feels sluggish for distant users is latency. Fix it by being closer, or by making fewer round trips.
• A transfer that takes too long for a large file is bandwidth, or the window size below.

Why one stream cannot fill a fast port

TCP can only have so much data in flight before it must wait for an acknowledgement. That ceiling is the bandwidth-delay product:

throughput = window size / round-trip time

With a 64 KB window and 100 ms RTT, a single stream tops out around 5 Mbit per second — on a 10 Gbit port. Window scaling raises the ceiling, but the principle stands: over distance, a single connection will never saturate a fast link.

Which is why iperf3 -P 8 gives a completely different number from iperf3 with one stream, and why a single-threaded download is a poor test of a port. See speed testing and benchmarking.

What to do about each

Latency

Host closer to your users. Reduce round trips: keep connections alive, enable HTTP/2 or HTTP/3, inline what is small, cache what is repeated. See HTTP/2, HTTP/3 and QUIC and caching and CDNs.

Throughput over distance

Raise the buffers, enable BBR, use parallel streams. See TCP tuning and BBR.

Throughput locally

Then it genuinely is the port, the disk or the machine — measure which before buying anything.

The number that actually hurts

For most applications it is neither of the above: it is the time your own code spends before a byte leaves. A 300 ms database query adds more to the user's experience than the entire network path within Europe.

Measure time to first byte against total time. If first byte is slow, the server is thinking — see diagnosing a slow server. If first byte is fast and the rest is slow, that is the network.

What Amsterdam buys you

Roughly 5–10 ms to the Randstad, 10–20 to London, Frankfurt, Paris and Brussels, 20–35 to most of the rest of western and central Europe, and 75–90 to the US east coast. For European users that geography removes most of the latency argument before you tune anything — see why Amsterdam.

And if a particular network reaches us badly, tell us. Routing is ours and a path can often be improved — see routing problems.

---

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base