THE PROBLEM //
Download speed was not the issue. The problem was what happened when the
connection was busy.
Large downloads or uploads could make ordinary browsing, gaming, and
anything else on the network feel laggy. A conventional speed test still
showed the expected speeds, but it didn't explain the latency while
under load.
WHAT THE NUMBERS SAID //
Speed test results looked fine for my current ISP plan. A Cloudflare
speed test showed 95 to 100 Mbps down and about 11 Mbps up. Not great by
any means, but close to what I was paying for.
The problem showed up under load: a phenomenon called bufferbloat. Idle
latency was normal, usually somewhere around 20 to 30 ms, but even
moderate upload traffic could push loaded latency past 400 ms. One test
measured 455 ms. This was not okay.
That also explained why a normal speed test could look healthy while the
connection felt like shit during an upload. The bandwidth was there, but
smaller data packets were stuck waiting in the queue, adding delay and
jitter.
THE CHANGE //
The ISP gateway remained upstream because Bell forces me to keep their
garbage hardware in the chain, but routing and wireless duties were
moved to a TP-Link Archer AX23 running OpenWrt. I named it Firelink,
following the same naming scheme as everything else on my network.
SQM was enabled on the WAN using CAKE. I set the limits slightly below
my actual line speed so Firelink became the bottleneck and could manage
the queue instead of letting it form somewhere upstream.
THE SETTINGS //
The final setup was simple:
Interface: WAN
Queue discipline: CAKE
Queue setup script: piece_of_cake.qos
Download limit: 95000 kbit/s
Upload limit: 9000 kbit/s
I kept the download limit close to my actual line speed and pulled the
upload limit back far enough for Firelink to control the queue.
WHY IT HELPED //
Without smart queue management, one large transfer fills up the
available buffer, and everything else queued behind it, whether that's a
game packet or a page load, just has to wait. Once Firelink was
enforcing the queue instead of letting it back up somewhere upstream,
that stopped happening.
THE TRADE-OFF //
The cost is a slightly lower number on a raw bandwidth benchmark, since
the router is deliberately keeping traffic under the configured limits
instead of letting it burst as high as the line allows.
That trade was clearly worth it. A benchmark number doesn't mean much if
the connection stutters every time someone else on the network kicks off
a download. Consistency mattered more than the ceiling.
RESULT //
The difference was obvious right away.
I set up Speedtest Tracker on Nexus to run daily and keep a proper
record instead of relying on one-off tests. Across 17 recorded runs,
loaded download and upload latency both averaged around 9 ms instead of
climbing past 400 ms.
Speeds settled around 90 Mbps down and 8.5 Mbps up. I gave up some peak
bandwidth, but it meant activity on the network could continue without
me getting desynced and shot behind walls.
The plan didn't improve my speeds. In fact, it restricted them. But that
also meant the connection stopped feeling broken and laggy whenever
someone used the upload.
LESSON //
Connection quality is not defined by raw bandwidth.
For my network, managing the queue was a much larger improvement than
chasing the highest possible speed-test number.