Bandwidth, throughput, and latency describe different limits

A gigabit port, a fast speed-test result, and a responsive website describe different properties. The port is one local capacity limit. A transfer measures what a particular pair of endpoints delivered under a particular workload. A response time includes waiting that may happen before the useful data arrives. Choosing a server or troubleshooting a connection requires all three ideas, with enough context to make the numbers comparable.

Start with units and the application requirement

Network rates commonly use bits per second, while file sizes often use bytes. Divide a decimal megabit rate by eight to obtain its approximate decimal megabyte rate before accounting for protocol overhead. A nominal 80 Mbps payload rate would correspond to 10 MB per second in that arithmetic example. Do not compare an application's MB/s display directly with a provider's Mbps label.

Write down the workload before selecting a benchmark. A large backup values sustained transfer rate. A remote terminal values responsiveness. Video playback needs delivery fast enough to replenish its buffer across bitrate peaks. These requirements overlap, but a single ranking of servers by headline speed cannot express all of them.

Measure delivered throughput at the receiver

Use a controlled endpoint and a bounded test. If an authorized iperf3 server is available at the example address, four comparisons can be collected as follows:

iperf3 -c 192.0.2.10 -t 30 -i 1 -J
iperf3 -c 192.0.2.10 -t 30 -i 1 -P 4 -J
iperf3 -c 192.0.2.10 -t 30 -i 1 -R -J
iperf3 -c 192.0.2.10 -t 30 -i 1 -R -P 4 -J

Replace the documentation address with the real authorized endpoint. The iperf3 invocation reference explains reverse mode, parallel streams, duration, and JSON output. In reverse mode, the server sends data to the client; the client still initiates the test's control connection.

Save each result separately. Include tool versions, endpoint addresses, the selected interface, and the actual receiving rate. Parallel-stream throughput is an aggregate; it does not promise the same rate to one HTTP connection. Close temporary listeners and restore temporary firewall exceptions after the measurement.

Relate delay to data in flight

Round-trip time measures a journey out and back. It does not isolate one direction, especially when the paths are asymmetric. A true one-way measurement introduces clock synchronization and uncertainty requirements. The IETF's one-way delay metric describes those requirements. Avoid labeling half a ping RTT as a verified one-way delay.

For a sustained TCP transfer, rate multiplied by RTT gives an approximate bandwidth-delay product: the amount of data that must be in flight to sustain that rate. As an arithmetic example, 100 Mbps across a 0.2-second RTT corresponds to about 2.5 MB. The sender's congestion window and the receiver's advertised window can therefore matter on a long path. RFC 6349 discusses TCP throughput testing and these relationships.

This calculation is a diagnostic clue, not an instruction to force enormous buffers. Other limits may dominate, including loss recovery, application behavior, CPU, or access-link capacity. Record the actual window observations before changing a system setting.

Distinguish a local port from a complete path

The delivered rate cannot exceed the constraints encountered across the entire path. A 1 Gbps virtual interface does not establish how much capacity is available at a shared upstream link or a distant interconnection. Other traffic can consume resources outside either endpoint's control. Provider port specifications and measured application performance should therefore be reported as separate facts.

RFC 5136 provides terminology for network capacity and available capacity. A practical consequence is that a speed test to a nearby destination answers a narrower question than a transfer to the intended user. Test the actual direction and access network that the application depends on rather than substituting a geographically convenient benchmark.

Inspect variation instead of keeping only the average

A whole-test average can hide several seconds of very low delivery. Save interval results and inspect short rolling averages as well as the total. Compare quiet periods with busy periods using the same method. Do not claim a month of reliability from one short sample, even when the result is excellent.

For streaming, compare conservative delivered rates with the actual media bitrate and its peaks. Resolution alone does not determine bitrate: codec, source quality, encoding settings, and audio tracks contribute. A buffer can absorb a brief dip, but repeated or prolonged deficits will eventually exhaust it. State the bitrate assumption whenever judging a connection's suitability.

Keep the experiment reproducible and bounded

Check both endpoints for CPU or storage bottlenecks while testing. Confirm that the selected route does not use an unintended VPN, proxy, or relay. Keep one variable fixed while changing another, and retain raw measurements so the reasoning can be reviewed later.

An effective conclusion describes what was measured, what workload it supports, and what remains unknown. Capacity sets an upper boundary, throughput shows delivered work, and latency describes waiting. Their combination, observed over representative intervals, is more useful than the largest number displayed by a single benchmark.