Short answer: bandwidth describes capacity, throughput describes an observed delivery rate, latency describes delay, jitter describes delay variation, and loss describes packets that don't arrive within the measurement's limit. None of these numbers replaces the others.
Start with OSI and TCP/IP and duplex. The TCP example also uses receive and congestion windows.
Five different questions
Picture an automated car wash. Its conveyor can admit a certain number of cars per hour, but today's actual completions depend on demand, stoppages, and the exit queue. One driver's time inside is a different measurement from cars completed per hour. The same distinction applies to a 1 Gbit/s Ethernet port and a file download.
| Measurement | Network meaning | Car-wash equivalent |
|---|---|---|
| Bandwidth or capacity | A stated rate limit at a specified layer, such as a 1 Gbit/s Ethernet link | The conveyor's maximum admission rate |
| Throughput | Bits or bytes delivered per second, measured over a stated interval and layer | Cars actually completing the wash per hour |
| Goodput | Useful application data delivered per second, excluding protocol overhead and duplicate retransmissions | Completed washes, excluding time spent repeating a wash |
| Latency | One-way delay or round-trip time (RTT), explicitly labeled | One driver's elapsed time through the wash, including waiting |
| Jitter | Variation in packet delay; the statistic depends on the tool | How much that elapsed time differs from car to car |
| Loss | Sent packets not received within a defined time limit | Cars turned away rather than processed |
The analogy stops at recovery: TCP can retransmit missing bytes; an IP packet doesn't drive around for another attempt on its own. Also, radio engineers use bandwidth for spectrum width in hertz. Here, unless we say MHz, we're discussing data capacity in bits per second.
The slowest stage sets a ceiling
A laptop's 1000BASE-T link doesn't make every hop gigabit. If a remote service is reached through a 100 Mbit/s bottleneck, the file cannot cross that bottleneck faster than its available capacity. Other traffic, Ethernet/IP/TCP headers, retransmissions, storage, CPU, and application behavior can lower useful delivery further. At the car wash, a fast entrance doesn't make the slower dryer finish sooner.
Worked example: how long should a transfer take?
Use consistent units. A decimal MB is 1,000,000 bytes; a MiB is 1,048,576 bytes. One byte is eight bits. If a 250 MB file achieves a steady 80 Mbit/s of application goodput, the estimate is 250 × 8 / 80 = 25 seconds.
| File size (MB) | Goodput (Mbit/s) | File size (Mbit) | Transfer time (s) |
|---|---|---|---|
| 250 | 80 | 2000 | 25 |
This is a calculation, not a benchmark. It excludes connection setup and assumes the rate remains steady. Don't subtract TCP headers again if your input is already application goodput. For a small HTTP request, DNS, TLS setup, server processing, and multiple dependent requests may matter much more than this bulk-transfer estimate.
Latency can limit a single TCP flow
For TCP planning, the bandwidth-delay product uses capacity and round-trip time. At 100 Mbit/s and 40 ms RTT, 100,000,000 × 0.040 / 8 = 500,000 bytes would be in flight to sustain that rate in a simplified steady-state model. A flow limited to a 65,536-byte effective window has a window/RTT ceiling of about 13.1 Mbit/s, before other constraints. In the car wash, a conveyor needs enough cars in progress to keep all stages occupied; a rule permitting just one car at a time wastes capacity.
Actual behavior depends on cwnd, advertised rwnd, pacing, congestion control, and application demand. Modern operating systems often autotune buffers. Measure before overriding them. Adding parallel flows can increase aggregate throughput while hiding why a single flow is slow.
Variation and loss need context
An ICMP echo measurement reports RTT, not one-way delay. Halving it assumes symmetry that may not exist. One-way timing needs appropriately synchronized clocks and a stated measurement method. Report percentiles and the observation window, not only an average that hides short stalls.
A voice receiver uses a playout buffer to smooth irregular arrivals. A larger buffer tolerates more variation but adds delay, like holding finished cars until they can leave regularly. Packets arriving after a playback deadline may be unusable even though the network eventually delivered them. RTP's jitter estimate and another tool's maximum-minus-minimum delay are different statistics; don't compare them as identical numbers.
If 20 of 1,000 test packets are missing by the chosen deadline, observed loss is 2%. That sample says nothing by itself about where loss occurred. TCP retransmission indications can also result from reordering, delayed acknowledgments, or a capture that missed packets. Correlate endpoint observations with interface errors and queue drops.
Choose the next check
| Symptom | Check | Interpretation |
|---|---|---|
| Upload makes calls stutter | Compare RTT and call loss/jitter before and during the upload | A loaded upstream queue is plausible even if downstream capacity is high |
| Wi-Fi reports a high link rate, download is slow | Compare wired delivery, airtime use, retries, and AP uplink speed | Negotiated PHY rate excludes sharing and overhead; it isn't goodput |
| Only one application is slow | Separate DNS, connection, TLS, and response timings | Server work or an application dependency can dominate a healthy network path |
| One traceroute hop shows missing replies | Check the destination and subsequent hops across repeated samples | A router can rate-limit replies while forwarding traffic normally |
Keep endpoints, direction, protocol, duration, and load conditions in the record. Run load-generating tests only on an approved path and within an agreed rate and time window. A throughput test can create the congestion you're investigating.
Related topics
Continue with TCP flow and congestion control, ICMP and traceroute, and HTTP transport behavior.
Sources
- RFC 5136: defining network capacity.
- RFC 6349: TCP throughput testing, especially the measurement method and bandwidth-delay product. Historical OS examples are not current tuning recommendations.
- RFC 3393: IP packet delay variation.