Bandwidth vs latency vs throughput — TL;DR
Understanding "bandwidth vs latency vs throughput" explains why a connection can test "fast" but still feel slow in daily use. Here’s a concise primer you can use to diagnose problems quickly and pick fixes that match your application's needs.
Quick definitions
Bandwidth — theoretical link capacity (e.g., Mbps/Gbps). Good for bulk transfers.
Latency (RTT) — time for a packet to travel round-trip. Critical for responsiveness, VoIP, and interactive apps.
Throughput — the actual data rate achieved during transfers (what users perceive).
Tip: user experience is usually ruled by throughput + latency/jitter, not bandwidth alone.
Measurement shortcuts
- Use ping for RTT/jitter, traceroute for path issues, and iperf for throughput/throughput vs bandwidth checks.
- Browser speed tests show bandwidth but can hide latency-driven issues.
- Run tests from both client and server sides and at different times to spot contention.
Common misconceptions
- "Higher bandwidth always equals faster user experience" — false. Small transactions and interactive apps are latency-sensitive.
- "A single speed test tells the whole story" — false. Look at RTT, packet loss, and sustained throughput.
Quick troubleshooting checklist
- Confirm link capacity (bandwidth) vs subscribed rate.
- Measure RTT and jitter to key servers.
- Test throughput with iperf (one-way and bi-directional).
- Check for packet loss and retransmissions (TCP).
- Inspect Wi‑Fi contention and duplex/cabling issues on wired links.
- Verify device CPU, bufferbloat, and QoS policies.
- Isolate by testing single-client vs multi-client scenarios.
Want the full explanations, measurement examples, and a step-by-step troubleshooting checklist? Read the complete guide and tools here: Full guide & troubleshooting checklist
If you're troubleshooting a specific problem (VoIP lag, slow backups, or web app slowness), click through — the guide maps common symptoms to the most likely metric to test first.