A nine patch series posted to the Linux kernel mailing list on Monday, August twenty fourth, 2026, fixes a queueing problem in ath11k, the mainline driver for Qualcomm WiFi 6 chipsets found in a large share of access points and laptops. The driver keeps no queue of its own, so during a saturated download every queued byte sits in the hardware transmit rings where there is no active queue management and no flow separation. Handing that queue back to mac80211 drops latency under load on an IPQ8074 access point from 155 milliseconds to 22 milliseconds, and one patch in the series is worth 2.2 times the throughput at identical latency.
The short answer
Julius Bairaktaris posted a nine patch series to the Linux kernel mailing list on August 24, 2026 that gives ath11k a real transmit queue under mac80211 control. The driver currently advertises neither NL80211_EXT_FEATURE_AQL nor NL80211_EXT_FEATURE_AIRTIME_FAIRNESS, so FQ-CoDel and airtime queue limits never engage and everything backs up in the hardware rings. Measured on an IPQ8074 access point, latency under load falls from 155 ms to 22 ms once the best effort limit is tightened, at a cost of about 21 percent of peak throughput. The series is under review, not merged.
If you have ever been on a call that fell apart the moment somebody in the same room started a large download, you have met this bug. It has a name, bufferbloat, and it has had well understood fixes in Linux for over a decade. The interesting thing about this patch series is where those fixes were not being applied.
The queue that was not there
ath11k drives Qualcomm WiFi 6 hardware, which covers a large amount of shipping equipment: IPQ series access point silicon, and the QCA6390 and QCN9074 parts that turn up in laptops and in add in cards. It is not an obscure driver.
What it does not have is a queue of its own. mac80211, the kernel's shared 802.11 layer, hands frames down and the driver pushes them straight into the hardware transmit rings. Those rings are deep and they are first in first out. There is no active queue management inside them and no notion that one flow is a video call and another is a file transfer.
So on a saturated download, the rings fill with that download. Every other packet on the link waits behind that backlog. The throughput number stays healthy, which is why this kind of problem survives so long: the metric most people measure is the one that is not broken.
The fix was already in the kernel
The part that makes this worth reading is that mac80211 already contains the machinery. It has FQ-CoDel for flow separation and it has airtime queue limits, which cap how many bytes a station can have sitting in hardware at once, so the queue that matters stays in software where an algorithm can reorder it.
A driver opts into that by advertising two feature flags, NL80211_EXT_FEATURE_AQL and NL80211_EXT_FEATURE_AIRTIME_FAIRNESS. ath11k advertises neither. The good code path exists on the machine and is simply not reachable on this hardware.
The series, from developer Julius Bairaktaris, puts the queue back under mac80211's control and turns the flags on. Nine patches, just over 150 lines. Most of it is plumbing. The author notes that the work was assisted by an AI model, which is a detail that would have been remarkable a year ago and is now common enough on the networking lists to have become its own discussion.
The numbers, including the cost
The measurements were taken on an IPQ8074 access point, and the honest way to read them is as three rows rather than one headline.
Stock ath11k gives 94.6 megabits per second at 155 milliseconds of latency under load. With the series applied at its default limit, 94.0 megabits per second at 157 milliseconds, which is to say no measurable change at all. With the best effort queue limit tightened to 500 and 1000, 74.3 megabits per second at 22 milliseconds.
That is the whole story in three lines. The series does not change behaviour on upgrade, it exposes a control. Taking the control costs about 21 percent of peak throughput and returns a factor of seven in latency. For anything interactive that is not a difficult trade, and for a link whose only job is bulk transfer it is the wrong one.
One patch is called out separately. Patch six, described as a completion driven scheduling round, is worth 2.2 times the throughput at identical latency and nothing at the default limit. That shape is characteristic: it is not adding capacity, it is stopping the driver from sitting idle waiting for transmit completions while airtime goes unused.
What to check on your own equipment
None of this is merged, so there is nothing to install. But the surrounding machinery is worth knowing, because the same controls already exist for drivers that do advertise the flags.
On a Linux access point with debugfs mounted, the airtime queue limit state lives under the mac80211 tree, one directory per PHY. The per access category table gives a low and a high limit for each of the four categories, voice, video, best effort and background, in that index order. Best effort is index 2 and it is where ordinary traffic lands, which is why it is the one the ath11k measurements tightened.
The habit worth building is on the measurement side rather than the tuning side. Peak throughput is the number every tool reports by default and it is the number this class of bug leaves untouched. What you want is latency while the link is saturated, which means running a load and a latency probe at the same time and reading the second one. Tools built for exactly that, such as flent, exist precisely because the obvious measurement misses the problem.
Why this keeps happening
Bufferbloat fixes have been in the kernel since the early 2010s and the wireless specific pieces, airtime fairness and airtime queue limits, landed years ago. The recurring failure is not in the algorithms. It is that each driver has to opt in, and opting in requires somebody to notice that a particular driver never did.
ath11k is a reminder that the presence of a good default in Linux says nothing about whether the hardware in front of you reaches it. That is worth carrying to other subsystems too. If your link behaves badly under load and the throughput looks fine, the first question is not whether the kernel has a fix. It is whether your driver ever asked for it.
Sources and further reading
- Linux ath11k Driver Improvements For Qualcomm WiFi 6 Hardware Yields 7x Lower Latency, Phoronix, August 24, 2026
- ath11k queueing patch series cover letter, Linux kernel mailing list, August 24, 2026
- About ath11k, Linux Wireless documentation
- Phoronix ath11k discussion thread, Linux.org, August 2026
Frequently asked questions
What is actually wrong with ath11k today?
The driver has no software queue, so mac80211 hands frames straight through to the hardware transmit rings and forgets about them. Those rings are deep, first in first out, and completely unaware of flows. That means a bulk download fills them with its own packets, and everything else on the link queues behind that backlog. mac80211 already ships the machinery to prevent this, FQ-CoDel for flow separation and airtime queue limits to cap how much sits in flight, but a driver has to opt in by advertising NL80211_EXT_FEATURE_AQL and NL80211_EXT_FEATURE_AIRTIME_FAIRNESS. ath11k advertises neither, so the smart layer is present in the kernel and simply not reachable on this hardware. The symptom is classic bufferbloat: fine throughput, terrible responsiveness the moment the link is busy.
How much does it cost when the limit does not bind?
Essentially nothing, which is the part that makes the series plausible for merging. The measured numbers on an IPQ8074 access point are 94.6 megabits per second at 155 milliseconds stock, and 94.0 megabits per second at 157 milliseconds with the series applied at its default limit. That is a rounding error in both directions. The gains only appear once you actually tighten the limit: with the best effort queue capped at 500 and 1000, throughput drops to 74.3 megabits per second and latency falls to 22 milliseconds. So the series does not silently change your access point's behaviour on upgrade. It gives you a control you did not previously have, and the default position of that control is roughly where you already were.
Is this a straight win, or is there a trade off?
There is a trade off and the numbers make it explicit. Going from 155 milliseconds to 22 milliseconds costs about 21 percent of throughput, 94.6 down to 74.3 megabits per second. Whether that is a good deal depends entirely on what the link carries. On an access point serving video calls, remote shells, gaming or anything interactive alongside background transfers, giving up a fifth of peak throughput to cut latency by a factor of seven is not a close call. On a link whose only job is to move a large file as fast as possible, it is the wrong trade and you leave the default alone. The useful thing about the series is that it makes this a decision rather than a fixed property of the driver.
Which patch does what, and which one is the interesting one?
The series is nine patches and just over 150 lines of code in total, which is small for the effect. Most of it is plumbing: putting the queue under mac80211's control and advertising the feature flags so the existing FQ-CoDel and airtime queue limit code paths engage. The one the author singles out is patch six, a completion driven scheduling round, which is described as worth 2.2 times the throughput at identical latency and nothing at all at the default limit. That combination is the signature of a scheduling fix rather than a capacity fix: it does not add headroom, it stops the driver from leaving airtime unused while it waits for completions.
When will this land, and what can I do in the meantime?
It is under review on the kernel mailing list as of August 24, 2026, and it is not merged. Wireless driver changes of this shape typically spend a cycle or two in review before reaching a mainline release, so treat this as a 2027 thing for stable distributions rather than something to plan around now. In the meantime the checks are worth running anyway. If your access point uses a driver that does advertise airtime queue limits, such as ath9k or ath10k, the mac80211 debugfs knobs already exist and the same trade off is already available to you. And measuring latency under load on your own link, rather than peak throughput, is the habit this whole class of fix rewards.