Troubleshooting performance and throughput

Why this matters

Performance faults are harder than outages. An outage is binary and everyone agrees it is happening; "the network is slow" is subjective, intermittent, and frequently not the network at all.

Objective 5.4 gives you the vocabulary to make it objective. Bandwidth, throughput, latency, jitter and packet loss are different measurements with different causes, and the first useful step in any performance complaint is deciding which one you actually have.

The lesson

Bandwidth, throughput capacity and the difference

Bandwidth is the theoretical maximum capacity of a link — 1 Gbps on a gigabit interface. It is a rating, not a measurement.

Throughput capacity is what you actually achieve. It is always lower, and the gap is where the diagnosis lives. Losses come from protocol overhead, congestion, errors and retransmission, the performance of the devices at each end, and the round-trip time.

That last one surprises people. TCP can have only so much data unacknowledged at once — the window — so on a long, fast path the sender spends much of its time waiting for acknowledgements. A 1 Gbps link to another continent will not deliver 1 Gbps for a single TCP stream no matter how clean it is. This is the long fat network problem, and the answer is window scaling or parallel streams, not more bandwidth.

The practical consequence: when someone says "we have a gigabit link and only get 400 Mbps", that may be entirely normal, and the useful question is what the path and the protocol are, not what the interface is rated at.

Congestion, contention and bottlenecking

Congestion/contention is demand exceeding capacity at some point. Multiple flows compete, queues build, latency rises and — when the queue is full — packets are dropped.

The symptoms distinguish it from other faults: performance is worst at peak times and recovers when demand falls, the interface shows rising drops rather than CRC errors, and latency rises as utilisation climbs. That time-of-day correlation is the strongest clue.

Bottlenecking is the specific point that limits the whole path. Every path has one, and performance is governed by it alone — upgrading anything else changes nothing. Common bottlenecks: the internet circuit, a saturated uplink between an access switch and distribution, a server's own NIC or disk, or a firewall doing deep inspection at a rate below the link speed.

Finding the bottleneck is the entire job. Work along the path checking utilisation at each hop, and remember the bottleneck may not be in the network — a slow application server produces exactly the same complaint.

Remedies: add capacity, apply QoS so that what matters is protected when the link is full, shift traffic in time, or move the content closer with a CDN or a cache.

Latency, jitter and packet loss

Three separate measurements, each affecting different applications.

Latency is delay — the time for a packet to travel, usually measured as round-trip time. Its components are propagation (distance, bounded by physics), serialisation (time to clock the bits onto the wire), queuing (time spent waiting in buffers, which rises with congestion), and processing.

Only queuing is really under your control, which is why a congested link shows latency climbing with utilisation. Latency to another continent is physics and cannot be engineered away — the only fix is to put the content nearer.

It affects interactive applications: voice, video, remote desktop, and anything chatty that does many round trips.

Jitter is variation in latency. Consistent 80 ms is fine for a call; latency swinging between 20 ms and 150 ms is not, because the receiver cannot assemble a smooth stream from packets arriving at irregular intervals.

Jitter is what makes voice sound choppy and robotic, and it matters more than absolute latency for real-time media. Its cause is variable queuing, so the remedy is QoS — giving voice a priority queue so it is not stuck behind bulk traffic. Jitter buffers at the endpoint absorb some, at the cost of adding latency.

Packet loss is packets that never arrive. Causes split into two families that need opposite fixes:

• Congestion, where queues overflow and packets are dropped deliberately. Interface drops rise. Fix with capacity or QoS.
• Errors, where packets are corrupted and discarded. Interface CRC errors rise. Fix the physical layer.

Reading which counter is climbing tells you which family you are in, and that is the single most useful diagnostic in this objective.

Small loss has outsized effects on TCP, because loss is interpreted as congestion and the sender slows down — 1% loss can cut throughput dramatically. UDP applications do not slow down; voice simply drops audio.

Wireless performance

Wireless has its own failure modes, and they account for most performance complaints in an office.

Interference is other transmitters in the same spectrum — neighbouring networks, Bluetooth, microwave ovens, cordless phones, and non-network sources like fluorescent ballasts. It causes corruption, retransmission and falling throughput.

The symptom pattern: performance varies with time of day and location, and is worse in 2.4 GHz. A Wi-Fi analyser or spectrum analyser identifies the source, which is the only way to distinguish interference from congestion.

Channel overlap is self-inflicted interference: nearby access points on overlapping channels. In 2.4 GHz the only non-overlapping channels are 1, 6 and 11, and any other choice guarantees overlap with neighbours.

The classic case is an office where every AP is on channel 6, or on "auto" with equipment that chose badly. Each AP interferes with the others, throughput collapses, and adding more APs makes it worse — which is the counterintuitive part worth remembering.

Signal degradation or loss is attenuation over distance and through obstacles. Concrete, brick, metal, lift shafts, foil-backed insulation and water (including people) all absorb signal. 5 GHz and 6 GHz attenuate faster than 2.4 GHz, so a network that works at 2.4 may be unusable at 5 in the same place.

Measured as RSSI, and the practical thresholds worth knowing: around −65 dBm or better for voice and video, −70 dBm adequate for data, and below −80 dBm effectively unusable.

Insufficient wireless coverage is the same problem viewed as a design fault rather than a physical one: not enough APs, badly placed, or with power set too low. A wireless survey and heat map from domain 3 is how you turn "it is bad over there" into a specific gap and a specific remedy.

Note the opposite error is also real: too many APs at full power creates excessive co-channel interference, and the fix is often reducing transmit power so cells are smaller and cleaner.

Client disassociation issues are clients dropping off the network. Causes include weak signal at the cell edge, interference, AP overload, power-saving features on the client, driver problems, and deauthentication attacks. Check whether it affects one client type — which points at drivers or power saving — or all clients in one area, which points at coverage or interference.

Roaming misconfiguration is the cause of the most common wireless complaint in a large building: a client that stays associated with a distant AP instead of moving to the strong one nearby. The client decides when to roam, not the infrastructure, and many clients hold on far too long — a phenomenon known as sticky clients.

Contributing factors: APs at too much power, so the old cell reaches further than it should; inconsistent configuration between APs, so the client sees them as different networks; and missing fast-roaming standards (802.11r, k and v) that help clients find and move to a better AP quickly.

The symptom is a user who walks to another part of the building and finds everything slow while showing a connected icon — and the BSSID is what proves it, because it shows which AP they are actually on.