Guides
What Is Bufferbloat?
Bufferbloat is excessive delay from persistent packet queues. Compare idle and loaded latency, separate download from upload, and verify any queue-management change.
Bufferbloat means excessive waiting time in packet queues. Some buffering is normal: it absorbs short traffic bursts. Trouble arises when queues stay too full, making calls or games sluggish while transfers continue. Queues can exist in a router, modem, other network equipment or an end device. A delay increase under load is a clue, not proof that your home router is faulty.
Compare idle, download and upload conditions
- Use the same device and test destination, preferably over Ethernet. Pause your own background transfers and record an idle baseline. Schedule load tests outside important calls because they deliberately use connection capacity.
- Measure latency while downloading, then while uploading, as separate trials. Use a test that reports idle and loaded latency, or observe repeated ping responses to the same responsive destination during a controlled transfer.
- Stop the transfer and check whether latency returns towards baseline. Repeat with the same settings. Record throughput, delay variation and any loss along with the direction of the load.
- Compare like-for-like figures. A rise from 12 ms idle to 150 ms loaded adds 138 ms; this example is arithmetic, not a universal failure threshold. A single maximum or missing ping reply does not identify a faulty queue.
Understand what the comparison can show
A reproducible rise during your transfers supports investigating queueing, but wireless contention, device processing, server load and changes elsewhere on the path can affect measurements too. Ethernet helps separate your Wi-Fi segment; it does not locate a particular modem, router or provider queue. Some speed tests explicitly measure loaded latency, so dismissing all speed tests as idle-only is wrong. Different methods and destinations need not produce the same result.
Reduce competing traffic first
- Move your large uploads, downloads or backups away from calls and games where practical. If the application supports a transfer-rate limit, leave room for other traffic and compare the result.
- Try Ethernet for a latency-sensitive device and investigate wireless coverage separately. A cable does not itself control queues on the Internet connection.
- Check the existing router's exact model, firmware and supported queue features before buying equipment. Newer hardware alone is not a guarantee of better queue management.
- If supported, use the maker's guidance for Smart Queue Management or an equivalent feature. Save the current configuration and baseline first; ordinary application priority is not automatically the same as active queue management.
SQM can combine traffic shaping, scheduling and active queue management. FQ-CoDel and CAKE are examples used by supported implementations, not features available on every router. Shaping may need a rate below the consistently available connection capacity so traffic does not build up in an unmanaged queue. Follow the implementation's instructions rather than a universal percentage. It can reduce maximum throughput, and router CPU capacity or a varying mobile connection can limit the result.
Verify a configuration change
- Check the affected download and upload directions, interface and rate units in the maker's guide. For example, 20 Mbps is 20000 kbit/s; entering 20 in a kbit/s field would impose a very different limit.
- Repeat the same idle and loaded tests after the change, noting both latency and achieved throughput. Change one setting at a time so you know what made a difference.
- Compare normal calls or games afterwards. A better test grade is useful evidence but does not guarantee every application's experience or repair an unrelated fault.
- Keep the before-and-after results and restore the previous supported configuration if performance worsens. Ask the administrator or provider for help with a managed router rather than changing settings blindly.
If delay is already high while idle, or only one service struggles, investigate that problem separately instead of assuming bufferbloat. For persistent problems across devices, give support the test destination, times, connection type, load direction, router model and before-and-after results. Replace equipment only when its actual capabilities or measured limitation justify it.