Bufferbloat: why fast internet still lags -- and how to fix it

The short version

You pay for fast internet, but calls still freeze and games still lag the moment someone in the house uploads photos or a big file. That stall has a name — bufferbloat — and the good news is it's usually fixable in an afternoon, for free.

What's actually happening

Think of your internet connection like the checkout lanes at a grocery store. When traffic is light, everyone gets through fast. But cheap routers don't have an "express lane." When a big job comes along — a cloud backup, a video upload, a game update — it fills every lane with a giant cart. Now your small, urgent items (the little packets that carry your voice on a video call) have to wait at the back of the line.

Your speed test still says you're fast, because a speed test measures how much data you can move, not how long each piece waits in line. Bufferbloat is all about the waiting.

Why it matters to you

• Video calls turn choppy or freeze the instant someone uploads something.
• Online games get laggy and unfair, even though your "ping" looks fine when nothing else is running.
• Web pages feel slow to load whenever the connection is busy.

It's the single most common reason a "fast" connection feels broken — and it hides from ordinary speed tests.

How to fix it

The fix lives in your router. You're going to turn on a feature that adds a smart, fair line — a kind of express lane that keeps urgent traffic moving. It's usually called SQM, Smart Queue Management, or QoS.

First, find your internet speed. Run the speed test on this site and write down your download and upload numbers.

Then open your router's settings and turn the feature on:

If you have an ASUS router

1. In a web browser, go to router.asus.com and sign in.
2. Open Adaptive QoS → QoS.
3. Turn QoS on and choose Adaptive QoS (or Bandwidth Limiter).
4. Enter about 90% of your download and upload speeds. (Measured 500 down / 20 up? Enter 450 and 18.)
5. Save.

If you have a Netgear Nighthawk

1. Open the Nighthawk app, or go to routerlogin.net.
2. Find Dynamic QoS, turn it on, and let it detect your speed (or type it in).

If you have a TP-Link, eero, or Google Nest

• TP-Link: in the Tether app, open QoS and set your speeds.
• eero and Google Nest manage this automatically — there's little to change, and they already keep the line short.

If you rent your provider's router (or it has no such setting)

These often can't run a proper smart queue. You have two choices: ask your provider to enable QoS, or add a router that does it well (see the gear below) and let it manage the traffic.

One honest trade-off: setting your speeds to about 90% means you "give back" a little top speed. That's on purpose — it leaves just enough room to keep the line moving. You won't notice the missing 10%; you will notice calls that stop freezing.

How to check it worked

Come back and run the bufferbloat test again — ideally while someone uploads a big file or a backup is running. You want your latency "under load" to stay close to its resting number. A jump of only a few milliseconds, and a grade of A or B, means you've fixed it.

If your result was already good

If you scored an A or B here, your router is already handling this well — you don't need to change anything or buy anything. Just keep your router's firmware updated, and if you ever move to a faster internet plan, re-check this page, because a new speed can change the picture.

Want to go further?

If you'd like to squeeze out the best possible result, switch to the Advanced version of this guide — it shows the exact algorithms (fq_codel and CAKE) and settings that network engineers use.

Is this your problem?

Bufferbloat is the usual culprit behind these, even when your speed test looks perfect:

• "Fast internet but lag spikes" in Valorant, CS2, Apex Legends, Fortnite or Roblox — your ping is fine until someone else in the house streams or uploads, then it spikes.
• "Ping spikes on ethernet." A wired connection rules out Wi-Fi, so the queue building up is in your router itself. That is classic bufferbloat.
• Zoom or Teams freezes when you share your screen. Screen sharing saturates your upload, the router queues your video behind it, and the call stalls — even on a fast plan.
• "Zoom connection unstable but internet is fine." The speed test measures an idle line; bufferbloat only shows up when the line is busy, which is exactly when your call needs it.

What bufferbloat actually is

Bufferbloat is latency-under-load caused by standing queues in oversized, unmanaged buffers along your path — most often your router's WAN egress and the ISP's upstream equipment. When a bulk flow saturates the link, packets pile into a large FIFO buffer, and latency-sensitive flows (VoIP, gaming, DNS, TCP handshakes) inherit that queueing delay — often hundreds of milliseconds. Throughput tests miss it because they measure saturated bandwidth, not per-packet sojourn time.

The real fix: AQM / SQM, not "priority QoS"

Classic priority QoS reorders traffic but still feeds oversized buffers; it never controls queue depth. The fix is Active Queue Management plus a shaper — together, SQM:

• fq_codel — flow-queueing + CoDel (RFC 8290 / RFC 8289). Isolates flows and drops or ECN-marks to hold sojourn time near a 5 ms target. Lighter on CPU.
• CAKE — Common Applications Kept Enhanced, fq_codel's successor: integrated shaper, built-in flow isolation, link-layer overhead compensation, optional DiffServ, and NAT/host fairness. Preferred where the CPU can keep up; slightly heavier than fq_codel.

Because you can only manage a queue you own, SQM shapes to just below your true line rate, moving the bottleneck into your router, where the AQM runs.

Setting the shaper

• Set download and upload to ~85–95% of measured line rate. Start at 90% and tune down if latency still spikes.
• Account for link-layer overhead — this is what people get wrong:
  • DOCSIS (cable): CAKE docsis keyword; ~85–90% down, 90–95% up.
  • PPPoE (DSL/VDSL): pppoe-ptm or ethernet + overhead bytes; VDSL2 often needs overhead 34.
  • Fiber/Ethernet handoff: ethernet (38 bytes).
• Prefer shaping egress (always yours to control). SQM handles ingress via an IFB device + policing, which is less precise — hence the more conservative download percentage.

OpenWrt (the reference implementation)

1. Install luci-app-sqm (pulls sqm-scripts).
2. Network → SQM QoS → add an instance on wan.
3. Queue discipline: cake, script piece_of_cake.qos (or layer_cake.qos for DiffServ).
4. Enter download/upload in kbit/s; set the link-layer overhead.

Equivalent /etc/config/sqm:

• download 460000 (~90% of 500 Mbit), upload 18000 (~90% of 20 Mbit)
• qdisc cake, script piece_of_cake.qos, linklayer ethernet, overhead 18

Verify: tc -s qdisc show dev eth1 — watch drops/ecn_mark rise and backlog stay low under load.

pfSense / OPNsense

Use fq_codel (or CAKE via plugins) in Limiters/Shaper: two pipes (WAN-in / WAN-out) at ~90% of line rate, scheduler fq_codel, floated onto floating rules matching all WAN traffic. Enable ECN.

Hardware reality (CPU is the ceiling)

SQM is CPU-bound — the shaper runs in software, so your router's processor sets the maximum speed you can shape. Rough guide: a dual-core ARM Cortex-A7 at ~650 MHz tops out near 200 Mbit/s with CAKE; older MediaTek MT7621/MIPS can't sustain high-speed SQM on current OpenWrt. For gigabit SQM you want modern silicon — MediaTek Filogic 830 (MT7986), Qualcomm IPQ8074, or Broadcom BCM4908 class — or x86 (pfSense/OPNsense). If the CPU can't shape at your plan speed, SQM will cap you below it, so size accordingly. If you're constrained, fq_codel costs less CPU than CAKE.

Verify properly

Run a bidirectional saturating test (Waveform's bufferbloat test, or flent rrul against a nearby netserver) and read P99 latency under load, not the average. Target: within ~0–20 ms of idle RTT. Test Wi-Fi separately — SQM shapes the WAN, not the air; Wi-Fi has its own airtime bufferbloat. OpenWrt airtime fairness and current drivers help, but wired results won't reflect Wi-Fi queueing.

Trade-offs & gotchas

• Expect ~5–15% throughput loss for bounded latency; enable ECN to recover some.
• Bridge the ISP modem/router, or you'll double-buffer and double-NAT and defeat your SQM.
• Re-tune after any plan speed change; a shaper set for 100/10 throttles a new 500/50 plan.