Your router has a waiting room with no maximum, and everyone in it keeps waiting. That is why your ping jumps the moment someone starts an upload.
The short answer
Bufferbloat is excess delay caused by buffers in the network that are too large and often full [1]. It shows up as a ping that climbs sharply while the line is busy, even though bandwidth is plentiful [5]. The cure is to keep queues short with active queue management (AQM), such as CoDel and FQ-CoDel [2][3][4]. On a home router, this usually means smart queue management (SQM) with a shaper set a little below your real line speed [5]. Our assessment: if your game lags only while the connection is loaded, test for bufferbloat before you pay for a faster plan.
How it works
- The queue. A router buffers packets when more arrive than the link can send. Gettys and Nichols write that large buffers were inserted all over the Internet without enough thought, and that they defeat the congestion-avoidance algorithms of TCP [1].
- The misdiagnosis. They add that the resulting long delays are often blamed on network congestion, which leads to the wrong fixes [1]. More bandwidth does not empty a queue that is always full.
- What you notice. OpenWrt describes it as most visible when a connection is heavily loaded with downloads or uploads. Latency rises, which hurts VoIP, video chat and online games [5].
- AQM. RFC 7567 strongly recommends testing, standardising and widely deploying active queue management in network devices [2]. CoDel controls the excess delay that bufferbloat creates, measures how long packets wait, and needs no configuration in normal Internet deployments [3].
- Flow queueing. FQ-CoDel mixes packets from many flows and reduces head-of-line blocking from bursty traffic. It isolates low-rate traffic such as DNS, web and video calls [4]. It is an Experimental RFC and ships in the mainline Linux kernel as fq_codel [4]. RFC 8289 tells implementers to prefer this multi-queue approach [3].
- SQM on a router. OpenWrt's SQM combines per-flow scheduling, AQM and traffic shaping. It needs CPU power and does not work with flow offloading [5]. Its guide sets the download and upload limits to 90 % of the speeds measured in a quiet network, picks cake or fq_codel as the queue discipline, and tells you to repeat the speed test [5]. Our reading: a shaper just below line speed moves the queue into the router, where the AQM can manage it.
A practical example
Run a speed test that reports latency during download and upload. OpenWrt names Waveform and Speedtest for this [5]. Without such a test, run ping (see our entry on ping and jitter) while a large upload runs. In OpenWrt's guide, one user's example on a cable line with 500/35 Mbit shows +18 ms (download) and +38 ms (upload) without SQM and +0 ms with cake at 90 % limits [5]. That is one user's result on one line, not a promise for yours. Whether our router offers a smart queue feature: not recorded. Our inventory (as of 14 to 16 Oct 2026) lists a UniFi router and firewall without its queue settings, so we show no measurements of our own network.
Checklist
- Measure ping idle, then again during a full upload and a full download [5].
- Measure the line speed first, when the network is quiet [5].
- Check whether your router offers SQM, smart queues or fq_codel [4][5].
- Set the shaper to about 90 % of the measured speed and test again [5].
- Turn off flow offloading where the router requires it for SQM [5].
- Raise the limit in small steps until latency starts to rise, then step back [5].
- Write down the settings and the test results with dates.