Gargoyle Forum

I've been doing some research into this issue after noticing that enabling QoS on my Gargoyle router seemed to make my internet feel slower and more erratic rather than better. I went digging into what's actually happening under the hood and wanted to share what I found because I think it explains why so many people on this forum report the same experience.

The short version

QoS doesn't make your internet faster. It trades peak throughput for lower latency under load. If you're not measuring latency under load, it just feels slower.

The default settings were designed for a different era

Most router QoS implementations — including Gargoyle's HFSC + qosmon — were designed around 2005–2010 network conditions:

• DSL with very limited upload (512 kbps was common) — upload saturation killing downloads was the main problem to solve
• 2–3 PCs in the house, no smartphones, no streaming services
• BitTorrent was the primary thing you wanted to throttle
• "Small packets = interactive traffic" was accurate — ACK packets, DNS, small HTTP requests

Today, none of those assumptions hold:

• Everything is encrypted HTTPS or QUIC on port 443 — the router literally cannot tell Netflix from a Zoom call from a video game. It all looks the same.
• Modern households have 15–25+ devices, most doing video of some kind
• Fixed wireless and DOCSIS connections have far more downstream capacity than the upload-constrained DSL lines QoS was designed for
• Streaming services (Netflix, YouTube) pre-buffer 30+ seconds ahead — an extra 500ms of latency during a burst is completely invisible to them
• TCP BBR (used by Google, YouTube, and most major CDNs now) handles congestion at the source much more intelligently than old Reno/CUBIC

What actually happens when a typical user turns on QoS

I traced through the sequence and it goes like this:

1. User enters their plan speed — say 23 Mbps — but the real sustained throughput is lower (mine was 18.5 Mbps measured). The router now applies QoS 2.5 Mbps too late, meaning the ISP's own queue fills up first, outside your control.
2. On startup or restart, qosmon enters an INIT phase where it throttles the link to near-zero for ~15 seconds to measure the baseline. Every router reboot or QoS restart punishes the whole household.
3. Because everything is port 443, almost all traffic lands in the "Normal" bulk class. The interactive/fast class sits mostly empty. QoS is categorising traffic the same way it would have without QoS.
4. The throughput ceiling is lower than without QoS — YouTube and Netflix start rebuffering.
5. User turns QoS off. Things feel better. QoS gets blamed.

The one scenario where it genuinely helps

There is a real use case and it's specific: someone is on a Zoom call or actively gaming while another person starts a large download. Without QoS, the download saturates the upload pipe — TCP ACK packets for the call/game get queued behind bulk data and the call breaks up.

With QoS, small interactive packets (ACKs, game state updates) jump the queue and the call stays clear.

That's the legitimate win. It's a real problem worth solving — but it only matters when the link is simultaneously saturated by bulk and interactive traffic.

What the industry actually moved toward

While home router QoS has stagnated, a few things have gotten genuinely better:

• CAKE + FQ-CoDel — A much smarter queuing algorithm that shapes per-flow automatically without needing you to accurately configure your bandwidth or understand RTT thresholds. Available in mainstream OpenWrt. You set your bandwidth 10% under the ISP max and walk away. This is the closest thing to "set and forget" QoS that actually works. Gargoyle doesn't have it yet.
• TCP BBR — Google's congestion control algorithm, used by YouTube, Google services, and now many CDNs. It reduces queuing at the server side by probing bandwidth instead of waiting for packet loss. This helps even without router QoS.
• ISP-side traffic management — Modern cable and fibre ISPs handle prioritisation themselves now, which is why removing router QoS often doesn't feel noticeably worse.

My practical findings from tuning

After a lot of monitoring I found two things that made the biggest difference on my setup (Gargoyle, fixed wireless, ~23 Mbps down / 7 Mbps up, 22 clients):

1. The configured bandwidth was the biggest problem. I had it set to my plan speed (21 Mbps) but the actual measured link ceiling was 18.5 Mbps. That 2.5 Mbps gap is where bufferbloat was happening — in the ISP's equipment, not mine. Lowering the configured value to just under the real ceiling (18 Mbps) immediately dropped my worst-case latency spikes from 160ms to 60ms. This is the single most important setting and most guides don't explain why it matters.
2. Test it under load, not idle. The only meaningful way to evaluate QoS is to start a large download on one device and run a bufferbloat test (waveform.com/tools/bufferbloat is good) at the same time. Idle latency looks the same with or without QoS. The difference only shows when the link is near saturation.

Honest recommendation

If you have people gaming or on voice/video calls at the same time as others doing large downloads, QoS is worth configuring carefully — with the bandwidth set to your real measured ceiling, not your plan speed. Run the bufferbloat test under load to confirm it's actually helping before you decide to leave it on.

If your household is mostly doing casual browsing and streaming at different times, QoS is probably not doing anything useful for you and the simplicity of leaving it off wins.

Would be interested to hear whether others have found the bandwidth misconfiguration issue as the culprit too — I suspect it's behind a lot of the "turned on QoS and things got worse" reports.

I’ve been using Gargoyle for many years and still have 5 sites connected via VPN, but I’ve never managed to get QoS working properly.

With AI available now, I decided to finally take a serious look at QoS and work out what the issue was. The results are above.

It looks like there’s a speed penalty when using QoS, and I’m wondering whether the feature is even worth that trade-off in 2026?