Une série de neuf correctifs publiée sur la liste de diffusion du noyau Linux le lundi 24 août 2026 corrige un problème de file d'attente dans ath11k, le pilote mainline des puces WiFi 6 de Qualcomm présentes dans une large part des points d'accès et des ordinateurs portables. Le pilote ne tient aucune file d'attente propre : lors d'un téléchargement saturant, chaque octet en attente séjourne dans les anneaux d'émission matériels, où il n'existe ni gestion active de file ni séparation des flux. Rendre cette file à mac80211 fait tomber la latence en charge d'un point d'accès IPQ8074 de 155 millisecondes à 22 millisecondes, et un correctif de la série vaut à lui seul 2,2 fois le débit à latence égale.
The short answer
Julius Bairaktaris a publié le 24 août 2026 une série de neuf correctifs sur la liste du noyau Linux qui dote ath11k d'une vraie file d'émission sous le contrôle de mac80211. Le pilote n'annonce aujourd'hui ni NL80211_EXT_FEATURE_AQL ni NL80211_EXT_FEATURE_AIRTIME_FAIRNESS, donc FQ-CoDel et les limites par temps d'antenne ne s'activent jamais et tout s'accumule dans les anneaux matériels. Mesurée sur un point d'accès IPQ8074, la latence en charge tombe de 155 ms à 22 ms une fois la limite best effort resserrée, au prix d'environ 21 pour cent du débit de pointe. La série est en revue.
Si vous avez déjà vu une visioconférence s'effondrer au moment précis où quelqu'un, dans la même pièce, lançait un gros téléchargement, vous avez rencontré ce défaut. Il a un nom, le bufferbloat, et ses corrections sont bien comprises dans Linux depuis plus de dix ans. L'intérêt de cette série de correctifs tient à l'endroit où ces corrections n'étaient pas appliquées.
La file d'attente qui n'existait pas
ath11k pilote le matériel WiFi 6 de Qualcomm, ce qui couvre une quantité importante d'équipements en service : le silicium de points d'accès de la série IPQ, ainsi que les puces QCA6390 et QCN9074 que l'on retrouve dans des portables et des cartes additionnelles. Ce n'est pas un pilote confidentiel.
Ce dont il ne dispose pas, c'est d'une file d'attente à lui. mac80211, la couche 802.11 partagée du noyau, lui transmet les trames et le pilote les pousse directement dans les anneaux d'émission matériels. Ces anneaux sont profonds et fonctionnent en premier entré premier sorti. Ils ne contiennent aucune gestion active de file et n'ont aucune notion du fait qu'un flux est une visioconférence et un autre un transfert de fichier.
Lors d'un téléchargement saturant, les anneaux se remplissent donc de ce téléchargement. Tous les autres paquets du lien attendent derrière cet arriéré. Le chiffre de débit, lui, reste bon, et c'est précisément pourquoi ce genre de problème survit si longtemps : la mesure que tout le monde effectue est celle qui n'est pas cassée.
Le correctif était déjà dans le noyau
Ce qui rend l'affaire intéressante, c'est que mac80211 contient déjà la mécanique. Il possède FQ-CoDel pour séparer les flux et les limites de file par temps d'antenne, qui plafonnent le nombre d'octets qu'une station peut avoir en attente dans le matériel, afin que la file qui compte reste en logiciel, là où un algorithme peut la réordonner.
Un pilote s'y inscrit en annonçant deux indicateurs, NL80211_EXT_FEATURE_AQL et NL80211_EXT_FEATURE_AIRTIME_FAIRNESS. ath11k n'annonce ni l'un ni l'autre. Le bon chemin de code est présent sur la machine et simplement hors d'atteinte pour ce matériel.
La série, signée du développeur Julius Bairaktaris, remet la file sous le contrôle de mac80211 et active les indicateurs. Neuf correctifs, un peu plus de 150 lignes. L'essentiel relève de la tuyauterie. L'auteur signale que le travail a été assisté par un modèle d'intelligence artificielle, un détail qui aurait été remarquable il y a un an et qui est désormais assez courant sur les listes réseau pour être devenu un sujet en soi.
Les chiffres, coût compris
Les mesures ont été prises sur un point d'accès IPQ8074, et la manière honnête de les lire consiste à retenir trois lignes plutôt qu'un titre.
ath11k d'origine donne 94,6 mégabits par seconde à 155 millisecondes de latence en charge. Avec la série appliquée à sa limite par défaut, 94,0 mégabits par seconde à 157 millisecondes, autrement dit aucun changement mesurable. Avec la limite de la file best effort resserrée à 500 et 1000, 74,3 mégabits par seconde à 22 millisecondes.
Toute l'histoire tient dans ces trois lignes. La série ne modifie pas le comportement à la mise à jour, elle expose une commande. Se saisir de cette commande coûte environ 21 pour cent du débit de pointe et rend un facteur sept sur la latence. Pour tout ce qui est interactif l'arbitrage n'est pas difficile, et pour un lien dont la seule mission est le transfert de masse c'est le mauvais choix.
Un correctif est distingué à part. Le sixième, décrit comme une passe d'ordonnancement pilotée par les complétions, vaut 2,2 fois le débit à latence identique et rien à la limite par défaut. Cette forme est caractéristique : il n'ajoute pas de capacité, il empêche le pilote de rester inactif à attendre des complétions d'émission pendant que du temps d'antenne se perd.
Ce qu'il faut vérifier sur votre propre matériel
Rien n'est intégré, il n'y a donc rien à installer. Mais la mécanique environnante mérite d'être connue, car les mêmes commandes existent déjà pour les pilotes qui annoncent les indicateurs.
Sur un point d'accès Linux avec debugfs monté, l'état des limites par temps d'antenne se trouve dans l'arborescence mac80211, un répertoire par PHY. Le tableau par catégorie d'accès donne une limite basse et une limite haute pour chacune des quatre catégories, voix, vidéo, best effort et arrière plan, dans cet ordre d'index. Best effort porte l'index 2 et c'est là qu'atterrit le trafic ordinaire, ce qui explique que ce soit la catégorie resserrée dans les mesures ath11k.
L'habitude à prendre se situe du côté de la mesure plutôt que du réglage. Le débit de pointe est le chiffre que tout outil affiche par défaut et c'est précisément celui que cette catégorie de défaut laisse intact. Ce qu'il vous faut, c'est la latence pendant que le lien est saturé, donc lancer une charge et une sonde de latence en même temps et lire la seconde. Des outils conçus exactement pour cela, comme flent, existent justement parce que la mesure évidente passe à côté du problème.
Pourquoi cela se reproduit
Les correctifs de bufferbloat sont dans le noyau depuis le début des années 2010 et les briques propres au sans fil, l'équité de temps d'antenne et les limites de file associées, sont arrivées il y a des années. L'échec récurrent ne vient pas des algorithmes. Il vient de ce que chaque pilote doit s'y inscrire, et que cette inscription suppose que quelqu'un remarque qu'un pilote donné ne l'a jamais fait.
ath11k rappelle que la présence d'un bon comportement par défaut dans Linux ne dit rien de la capacité du matériel devant vous à l'atteindre. Le constat vaut pour d'autres sous systèmes. Si votre lien se comporte mal en charge et que le débit paraît correct, la première question n'est pas de savoir si le noyau dispose d'une correction. C'est de savoir si votre pilote l'a jamais demandée.
Sources et pour aller plus loin
- Linux ath11k Driver Improvements For Qualcomm WiFi 6 Hardware Yields 7x Lower Latency, Phoronix, 24 août 2026
- Lettre d'accompagnement de la série ath11k, liste de diffusion du noyau Linux, 24 août 2026
- About ath11k, documentation Linux Wireless
- Fil de discussion ath11k, Linux.org, août 2026
Questions fréquentes
Qu'est ce qui ne va pas dans ath11k aujourd'hui ?
Le pilote n'a pas de file d'attente logicielle : mac80211 lui passe les trames, qui filent directement dans les anneaux d'émission matériels, et il les oublie. Ces anneaux sont profonds, en premier entré premier sorti, et totalement ignorants des flux. Un téléchargement volumineux les remplit donc de ses propres paquets, et tout le reste du lien attend derrière cet arriéré. mac80211 embarque déjà de quoi l'éviter, FQ-CoDel pour séparer les flux et les limites de file par temps d'antenne pour plafonner ce qui est en vol, mais un pilote doit s'y inscrire en annonçant NL80211_EXT_FEATURE_AQL et NL80211_EXT_FEATURE_AIRTIME_FAIRNESS. ath11k n'annonce ni l'une ni l'autre : la couche intelligente est présente dans le noyau et simplement hors d'atteinte sur ce matériel. Le symptôme est le bufferbloat classique, un débit correct et une réactivité désastreuse dès que le lien travaille.
Combien cela coûte t il quand la limite ne mord pas ?
Pratiquement rien, et c'est ce qui rend la série crédible pour une intégration. Les mesures sur un point d'accès IPQ8074 donnent 94,6 mégabits par seconde à 155 millisecondes en version d'origine, et 94,0 mégabits par seconde à 157 millisecondes avec la série appliquée à sa limite par défaut. C'est une erreur d'arrondi dans les deux sens. Les gains n'apparaissent qu'une fois la limite resserrée : avec la file best effort plafonnée à 500 et 1000, le débit tombe à 74,3 mégabits par seconde et la latence à 22 millisecondes. La série ne modifie donc pas discrètement le comportement de votre point d'accès à la mise à jour. Elle vous donne une commande dont vous ne disposiez pas, et la position par défaut de cette commande correspond à peu près à votre situation actuelle.
S'agit il d'un gain net, ou y a t il un compromis ?
Il y a un compromis et les chiffres le rendent explicite. Passer de 155 millisecondes à 22 millisecondes coûte environ 21 pour cent de débit, de 94,6 à 74,3 mégabits par seconde. Que ce soit une bonne affaire dépend entièrement de ce que transporte le lien. Sur un point d'accès qui sert des visioconférences, des sessions distantes, du jeu ou n'importe quoi d'interactif à côté de transferts de fond, céder un cinquième du débit de pointe pour diviser la latence par sept ne se discute pas. Sur un lien dont la seule mission est de déplacer un gros fichier au plus vite, c'est le mauvais arbitrage et on laisse la valeur par défaut. L'apport de la série est justement d'en faire une décision plutôt qu'une propriété figée du pilote.
Que fait chaque correctif, et lequel est le plus intéressant ?
La série compte neuf correctifs et un peu plus de 150 lignes de code au total, ce qui est peu au regard de l'effet. L'essentiel relève de la tuyauterie : remettre la file sous le contrôle de mac80211 et annoncer les indicateurs de fonctionnalité pour que les chemins FQ-CoDel et limites par temps d'antenne existants s'activent. Celui que l'auteur distingue est le sixième, une passe d'ordonnancement pilotée par les complétions, décrite comme valant 2,2 fois le débit à latence identique et rien du tout à la limite par défaut. Cette combinaison est la signature d'une correction d'ordonnancement plutôt que de capacité : elle n'ajoute pas de marge, elle empêche le pilote de laisser du temps d'antenne inutilisé pendant qu'il attend des complétions.
Quand cela arrivera t il, et que faire d'ici là ?
La série est en revue sur la liste du noyau depuis le 24 août 2026 et n'est pas intégrée. Des modifications de pilote sans fil de cette forme passent d'ordinaire un cycle ou deux en revue avant d'atteindre une version mainline, donc considérez le sujet comme une affaire de 2027 pour les distributions stables plutôt que comme quelque chose à planifier maintenant. En attendant, les vérifications valent d'être faites. Si votre point d'accès utilise un pilote qui annonce bien les limites par temps d'antenne, comme ath9k ou ath10k, les réglages debugfs de mac80211 existent déjà et le même arbitrage vous est déjà accessible. Et mesurer la latence en charge sur votre propre lien, plutôt que le débit de pointe, est l'habitude que toute cette catégorie de correctifs récompense.