QoS Does Not Lower Your Ping. It Stops It Exploding.

The single most common misunderstanding about router QoS is the expectation that it reduces your idle ping. It does not, and it cannot — your baseline latency is set by distance and routing, and no local setting changes physics. What QoS does is prevent your latency from collapsing when the connection is busy: the difference between 25ms while idle and 25ms while somebody uploads a video, instead of 25ms idle and 400ms under load. If your ping is only bad when the household is doing something, QoS is exactly the right fix. If your ping is uniformly high all the time, QoS will do nothing for you.

The Problem QoS Actually Solves: Bufferbloat

When a bulk transfer fills your upstream or downstream link, packets queue somewhere. Consumer modems and routers historically shipped with very large buffers, on the theory that dropping packets is bad. The result is that a saturating download or upload fills a buffer holding hundreds of milliseconds of data, and your game packets have to wait in line behind it. Latency under load balloons even though your line speed is unchanged. That is bufferbloat, and it is the reason a 1 Gbps connection can feel worse for gaming than a well-managed 50 Mbps one. Our bufferbloat explainer covers the mechanism in depth.

The measurable symptom is a big gap between idle latency and loaded latency. Run a ping while the line is quiet, then run the same ping while a large download is in progress. If the number triples or worse, you have bufferbloat, and QoS is your fix.

Legacy QoS vs Smart Queue Management

Two very different things are sold under the same three letters, and picking the wrong one is why most QoS setups underdeliver.

	Legacy priority QoS	Smart Queue Management (SQM)
How it works	Classifies traffic into priority tiers and sends high-priority packets first.	Actively manages queue depth with an algorithm like fq_codel or CAKE, keeping queues short so nothing waits long.
Needs to know your traffic	Yes — you must define rules by port, protocol, application, or device.	No. It fairly shares the link between flows automatically.
Handles encrypted / unknown traffic	Poorly. If it cannot classify a flow, it cannot prioritize it.	Well. Flow fairness does not require identifying what the flow is.
Effect on latency under load	Partial. Reduces delay for the traffic it correctly identifies, and only if the bottleneck is inside the router.	Large. Directly targets the queueing delay that causes the spike.
Typical result	Modest, inconsistent improvement.	Loaded latency close to idle latency.

If your router offers SQM, fq_codel, CAKE, or a setting described as "smart queues" or "bufferbloat", use that instead of building priority rules. Priority QoS is not useless — it still helps in specific cases, such as guaranteeing a slice for a console — but SQM addresses the actual cause rather than reshuffling the queue.

Why You Must Set Bandwidth BELOW Your Real Line Speed

This is the step people skip, and skipping it makes SQM do nothing at all.

SQM can only manage a queue it owns. If you tell your router your line is 500 Mbps and it truly is 500 Mbps, the router never becomes the bottleneck — the modem or the ISP's equipment fills up first, and their buffer is the one causing your latency spike. Your router's clever queue stays empty and useless. By setting the shaper slightly below your real throughput, you deliberately move the bottleneck into your router, where the algorithm can keep the queue short.

Practical guidance:

Start at roughly 90-95% of your measured speed in each direction on a stable connection like fiber or good cable.
On cable, DSL, or any line with variable speeds, start closer to 85%, especially on the upload side. Upload buffers cause most gaming pain.
Tune downward if loaded latency is still high, and upward if you are giving away more throughput than you need. Change one direction at a time and re-test.
If your router offers a link-layer or overhead setting, pick the one matching your connection type (for example a DOCSIS preset for cable, or PPPoE for DSL and some fibre services). Getting this wrong makes the shaper less accurate.

Step-by-Step Setup

Measure your real speed first. Run a speed test three times, wired, with everything else on the network idle, and use the lowest of the three rather than the best. Your ISP's advertised number is not the figure to use. Our guide to testing internet speed correctly covers the method.
Record your loaded-latency baseline. Start a large download, and while it runs, ping a nearby address continuously (ping -t 1.1.1.1 on Windows, ping 1.1.1.1 on macOS and Linux). Note the worst figures you see. This is the number you are trying to fix.
Find the QoS section in your router. Common locations: OpenWrt has SQM QoS under Network after installing the SQM package; ASUS routers list Adaptive QoS and Traditional QoS under Adaptive QoS; Netgear gaming models expose it through their gaming dashboard; many ISP-supplied routers hide a limited version under Advanced settings. If yours has no usable QoS at all, that is a hardware limitation — see our gaming router guide for what to look for in a replacement.
Enable SQM, not priority rules, if both are offered. Choose cake if available, otherwise fq_codel. On OpenWrt the standard pairing is the cake queue discipline with the piece_of_cake script; leave the defaults unless you have a reason to change them.
Enter your shaped bandwidth. Use 85-95% of the measured figures from step 1, download and upload separately. Save and apply.
Re-run the loaded-latency test. Same download, same continuous ping. Loaded latency should now sit within a few tens of milliseconds of your idle figure instead of hundreds.
Tune if needed. Still spiking? Drop the upload limit by 10% and re-test, then the download. Losing too much speed? Raise in 5% steps until latency starts degrading, then step back once.
Confirm from the gaming device. Run our ping and jitter test on the gaming PC while the household is active. It measures warm HTTPS round-trip time to nearby cloud endpoints rather than in-game packets, so read it as a proxy — but since the method is identical before and after, the comparison is valid.

Device Prioritization vs Traffic Prioritization

Once SQM is working, you may still want to bias the link toward one machine. Understand the two approaches before choosing:

Traffic prioritization classifies by what the packets are — game protocols, video, downloads. It fails quietly whenever traffic is encrypted or uses non-standard ports, which today is most of it. Modern game traffic is small and bursty, so a well-configured SQM setup already gives it excellent treatment without any classification.
Device prioritization classifies by which client sent the packets. It is far more reliable because a MAC address or IP is unambiguous. Pinning your gaming PC or console to the top tier is a sensible, low-risk configuration.
Per-host fairness is the better default on CAKE-capable firmware. Options that isolate hosts (commonly presented as per-host or dual-source/destination isolation) split the link fairly between devices rather than between flows, so one machine running twenty download threads cannot crowd out a console running one game session. On most home networks this alone removes the need for manual priority rules.

A practical rule: enable SQM with per-host fairness first, measure, and only add explicit priority rules if a specific problem survives.

Firmware and Hardware Reality Check

OpenWrt gives the most complete and transparent implementation via its SQM package, with direct access to fq_codel and CAKE. It is the reference standard if your hardware supports it.
ASUS Adaptive QoS is a capable stock implementation with a usable bandwidth-limiting mode; ASUS routers also expose Traditional QoS for manual rules. Merlin firmware on supported models adds finer control.
Netgear, TP-Link, and other gaming-branded models usually ship some form of prioritization; check whether it actually shapes bandwidth or only reorders queues, because the marketing rarely distinguishes.
Ubiquiti EdgeRouter, pfSense, and OPNsense support smart queueing at a level comparable to OpenWrt, with more configuration effort.
CPU is the ceiling. Shaping traffic is computation. A modest consumer router may only manage SQM cleanly up to a few hundred Mbps; beyond that it drops throughput or stops shaping accurately. If you have a multi-gigabit line, you need hardware sized for it — or you accept shaping at a lower rate in exchange for stable latency, which for gaming is often the better trade.

How to Know It Worked

The only meaningful verification is a loaded-latency comparison, not an idle ping. Record four numbers: idle latency, idle jitter, latency during a saturating download, and latency during a saturating upload. A correctly configured SQM setup keeps the loaded figures close to the idle ones — the exact gap depends on your line and hardware, but the difference between "barely moves" and "multiplies several times over" is unmistakable.

Watch jitter as well as average latency, since queueing delay shows up as variance long before it shows up as a higher mean — and that variance is what you actually feel in game. Keep expectations calibrated: if your idle ping to a game server is 90ms because the server is 3,000 km away, QoS will keep it at 90ms under load. That is the win. Getting it below 90ms is a matter of server choice and routing, covered in our guide to lowering ping.