Latency vs Bandwidth vs Throughput: What Is the Difference?

What Is the Difference Between Latency, Bandwidth and Throughput?

The quickest way to tell them apart is to ask where each number came from. Your contract states the network bandwidth, a file transfer measures the throughput, and a ping measures the latency.

Calling all three speed is how a team ends up buying bandwidth to fix a latency problem. That upgrade only pays off when bandwidth was the limit in the first place.

The table below compares the three on the terms that matter operationally.

1. Bandwidth Sets the Ceiling

Nothing you measure changes the number. An idle port at 3 a.m. and a saturated one at month end both still report 1 Gbps.

So a speed test will never return the figure printed on your contract, and that gap is normal rather than a fault.

2. Throughput Lands Below the Ceiling

Whatever rate a large file transfer settles at is the throughput. On a gigabit link it will sit well short of 1000 Mbps, every time.

Four things take the difference.

Once all of that is paid, 70 to 90 percent of the rated figure counts as a healthy link. Goodput narrows it further, counting only the application payload and ignoring headers and resent packets.

3. Latency Measures the Wait

A ping that comes back in 40 ms is reporting latency, and specifically the round trip. The one-way figure is roughly half of that, which is the number carriers quote in an SLA.

Distance sets the floor and no equipment can beat it. A packet needs roughly 5 microseconds per kilometer of fiber.

That works out to a hard minimum near 56 ms on a New York to London round trip, whatever you spend.

Real cables run longer than the straight line, which is why 70 ms is the figure that actually turns up in a ping.

Everything above that floor comes from hops, processing and queues. We have watched one congested access switch add 20 ms to a path with 2 ms of real distance in it.

Why Latency Caps Your Throughput

Move the same traffic onto a longer path and its usable throughput falls, even though the bandwidth figure never moves. That catches people out, and the reason sits inside TCP.

The receiver advertises a window in every ACK it returns. Until those ACKs come back, the sender has to stop.

So the window has to be at least as large as the link rate multiplied by the round-trip time, a figure called the bandwidth-delay product. Anything smaller leaves capacity sitting unused.

The figures below show how badly a small window plays out on a real link.

Nothing broke in that example. The link performed fine, the window simply could not cover the distance, and a second gigabit would have changed nothing.

Add 0.1 percent packet loss to that same path and throughput falls again, because TCP reads every dropped segment as congestion and halves the window. Long-distance links suffer worst, since each recovery costs another full round trip.

Does More Bandwidth Reduce Latency?

No, and a ping taken before and after an upgrade proves it. Moving a site from a 100 Mbps circuit to 1 Gbps leaves the round-trip time exactly where it was.

Propagation delay, per-hop processing and queue time are what add up to a latency figure. Bandwidth changes none of those.

One case looks like an exception. Push a link to 95 percent and packets start queuing at the interface, and that wait lands in your ping.

Adding capacity empties those queues and the ping falls back toward its floor. You removed congestion rather than shortening the path.

Once utilization sits comfortably below about 70 percent, more bandwidth stops helping latency entirely.

Which One Is Slowing Your Network?

The symptom usually points at one of the three, provided you know what to look for.

Match what users report against the likely cause before you change anything.

Two of those five rows point away from bandwidth. That ratio matches what we see in practice, and it explains why circuit upgrades so often disappoint.

Thresholds differ by traffic type, so a number that ruins a VoIP call barely registers on a backup job. The network performance metrics worth tracking come with their own ranges per workload.

Where Does Jitter Fit In?

Jitter is the variation in latency between packets, and it counts as a fourth measurement rather than a version of the other three.

A path averaging 40 ms sounds healthy. If individual packets arrive at 20 ms, then 90 ms, then 35 ms, a voice call still sounds broken.

Real-time traffic suffers because the receiver buffers packets to smooth playback. Wide swings overrun that buffer and the audio drops out.

Bulk transfers barely notice jitter, since TCP reassembles the data regardless of arrival order. One path can therefore serve file storage well and voice badly at the same time.