The difference between a slow network and a busy one

“The network is slow” describes a feeling, not a fault. Two quite different conditions produce that feeling, and telling them apart early saves you from fixing the wrong thing.

Busy

A busy link is running near capacity. Queues build, latency rises under load and falls when load drops, and throughput is roughly what the link can carry. Nothing is broken. There is simply more demand than capacity.

The signature is that latency correlates with utilisation. Graph both. If the curves move together, you have a capacity problem, and the answers are more capacity, less demand, or prioritising what matters through QoS.

Slow

A slow link is not carrying what it should. Utilisation is modest, yet throughput is poor. Something is wasting the capacity: retransmissions from packet loss, a duplex mismatch, an MTU problem forcing retries, a failing cable producing CRC errors, or a device doing something in software that should be in hardware.

Here latency and utilisation do not correlate. That is the tell.

Separating them in practice

# is the link actually full?
show interface | include rate|utilization
# is it losing packets?
show interface | include error|drop|CRC
# what does a clean test say?
iperf3 -c host -t 30

A link at 30% utilisation with rising errors is slow, not busy. A link at 95% utilisation with no errors is busy, not slow. A link at 95% with errors is both, and the errors came first.

Why it matters

The fixes are unrelated. Buying more bandwidth for a slow link wastes money and changes nothing, because the new capacity will be wasted the same way. Tuning QoS on a faulty link just prioritises which traffic gets corrupted. Diagnose which condition you have before you spend anything.