Latence Wi-Fi inexpliquée : et si le coupable était dans la carte réseau ?

Le packet coalescing, un réglage par défaut qui économise de l'énergie au prix de la réactivité, et que l'on pense rarement à vérifier.

Dans cet article, nous allons voir ce qu'est le packet coalescing, pourquoi il introduit de la latence invisible aux outils de supervision classiques, et comment le désactiver à l'échelle d'un parc avec PowerShell. Le script associé est disponible en open source : github.com/9LivesITSolutions/nic-latency-d0packetcoalescing.

Qu'est-ce que le packet coalescing ?

Sans coalescing, chaque paquet reçu est remonté au système dès son arrivée. Avec coalescing, la carte réseau les met en tampon et ne réveille le système que périodiquement, ou quand le lot est suffisant. Le processeur est moins sollicité, la consommation baisse, mais chaque paquet attend avant d'être traité. Selon le pilote et le matériel, ce délai va de 10 à 50 ms, contre environ 1 ms sans coalescing. Le retard est ajouté avant que l'application ne voie quoi que ce soit, donc aucun outil de supervision réseau classique ne le détecte.

Le but du réglage est l'économie d'énergie et de CPU. Sur un portable en veille ou sur batterie, c'est pertinent : laisser le processeur endormi plus longtemps prolonge l'autonomie. Le problème, c'est que le réglage reste actif même quand la machine est pleinement utilisée (état D0 dans le vocabulaire des pilotes). On paie alors la latence sans que le système soit réellement au repos.

Le terme recouvre plusieurs mécanismes voisins qui visent tous à réduire la sollicitation du processeur : coalescing de paquets au niveau de la carte, RSC (fusion de segments TCP côté Windows), LRO/GRO (côté Linux et hyperviseurs), modération d'interruptions. Cet article se concentre sur le coalescing de la carte réseau, en particulier Wi-Fi.

Pourquoi ce problème est difficile à diagnostiquer

Plusieurs raisons expliquent pourquoi ce réglage passe sous les radars :

• Rien n'est en erreur : le lien est établi, le signal est bon, aucun compteur ne dérive.
• Le réglage est d'origine. Personne ne l'a configuré, donc personne ne pense à le vérifier.
• Un ping isolé ne révèle pas la gigue qui pénalise les flux applicatifs réels.
• Les symptômes (à-coups, lenteurs intermittentes) ressemblent à un problème radio, donc l'investigation part naturellement sur le plan de fréquences, le roaming ou les bornes.
• Le nom de la clé de registre change selon le chipset, ce qui complique la vérification à grande échelle.

Quelles applications sont les plus touchées

Le débit brut est peu sensible au coalescing : un transfert de fichiers ne s'en ressent pas. En revanche, tout ce qui repose sur de petits échanges répétés subit le retard à chaque aller-retour :

• applications métier en mode requête/réponse ;
• sessions distantes (bureau à distance, applications publiées) ;
• authentification et appels RPC ;
• voix sur IP et visioconférence, sensibles en particulier à la gigue ;
• messagerie métier.

Sur des milliers d'échanges, un retard de quelques dizaines de millisecondes par paquet s'accumule et devient perceptible.

Dans quels cas le soupçonner

Quelques signes orientent vers le coalescing plutôt que vers un problème radio :

• latence ou gigue anormale sur un poste dont le signal Wi-Fi est pourtant bon ;
• lenteurs présentes en Wi-Fi mais absentes en filaire, sur la même machine ;
• problème concentré sur un modèle ou un chipset précis, plutôt que sur un secteur géographique ;
• supervision réseau au vert alors que les utilisateurs se plaignent ;
• postes sur secteur ou en utilisation continue, où l'économie d'énergie n'apporte aucun bénéfice.

La comparaison Wi-Fi/filaire sur un même poste, et la comparaison entre modèles de cartes, sont les deux tests les plus rapides pour orienter le diagnostic. Nous avons par exemple rencontré ce cas sur des chariots mobiles utilisés en continu : tous les indicateurs réseau étaient corrects, et le diagnostic a fini par pointer une puce Intel AX200 sous Windows 11. Après désactivation du coalescing, le comportement est redevenu normal.

Vérifier un poste à la main

Pour un test ponctuel sur une machine Windows :

# Repérer les propriétés liées au coalescing sur la carte
Get-NetAdapterAdvancedProperty -Name "Wi-Fi" |
    Where-Object DisplayName -match "Coalesc"

# Voir l'état de la gestion d'énergie de la carte
Get-NetAdapterPowerManagement -Name "Wi-Fi"

Selon le pilote, le réglage n'apparaît pas toujours sous le même nom ni dans la même vue, ce qui explique pourquoi la vérification manuelle ne passe pas à l'échelle sur un parc.

Le nom de la clé change selon le chipset

Un script qui ne cible qu'un seul nom de clé passe à côté d'une partie du parc. Nous avons aussi constaté que la commande PowerShell native Set-NetAdapterPowerManagement n'écrit pas de façon fiable dans la bonne clé selon les variantes de pilote. La solution retenue dans notre script est l'écriture directe dans le registre, avec détection de la clé réellement présente sur chaque carte.

Le piège du redémarrage de carte à distance

Pour que le nouveau réglage soit pris en compte, la carte réseau doit redémarrer. Sur un poste piloté en Wi-Fi via WinRM, ce redémarrage coupe la session qui vient de lancer la commande. Un script naïf s'interrompt alors en plein milieu, sans savoir ce qui s'est réellement passé.

Notre script gère ça en deux passes :

1. Première passe : écriture du registre, puis création d'une tâche planifiée unique, exécutée en SYSTEM, qui redémarre les cartes concernées indépendamment de la session WinRM (celle-ci peut tomber sans conséquence).
2. Pause d'environ 15 secondes, le temps que la carte redémarre et que la connexion revienne.
3. Seconde passe : reconnexion, lecture du journal d'exécution (C:\Windows\Temp\9Lives-NICFix.log), vérification de l'état réel, puis nettoyage de la tâche et des fichiers temporaires.

Chaque étape est journalisée, pour pouvoir comprendre précisément ce qui s'est passé sur chaque poste en cas d'écart.

Utiliser le script

Le dépôt contient deux scripts :

• Fix-NetworkPowerPerformance.ps1 désactive le coalescing, en local ou à distance.
• Check-NetworkPowerStatus.ps1 audite l'état actuel sur un ensemble de postes, sans rien modifier.

Trois modes sont détectés automatiquement selon les paramètres passés :

Quelques options utiles : -WhatIf pour un test à blanc, -ExportCsv pour conserver un rapport, -ThrottleLimit pour paralléliser l'exécution sous PowerShell 7 (repli séquentiel automatique en PowerShell 5.1). Déployé comme script de démarrage par GPO, il garantit aussi que le réglage reste appliqué après une mise à jour de pilote qui le réinitialiserait.

Bonnes pratiques avant de déployer

1. Mesurez la latence et la gigue sur quelques postes avant toute modification, pour pouvoir prouver l'effet ensuite.
2. Auditez d'abord avec Check-NetworkPowerStatus.ps1 pour connaître la répartition réelle des chipsets du parc.
3. Testez sur un poste pilote avant d'étendre par vagues.
4. Prévoyez une brève coupure Wi-Fi à chaque redémarrage de carte.
5. Mesurez à nouveau après coup, et conservez le rapport.
6. Surveillez les mises à jour de pilotes, qui peuvent restaurer la valeur par défaut sans prévenir.
7. Sur du matériel sur batterie dont l'autonomie est critique, l'arbitrage énergie/réactivité peut légitimement être différent : ne généralisez pas à l'aveugle.
8. Documentez la dérogation à la configuration constructeur.

Le script est documenté et distribué sous licence MIT : github.com/9LivesITSolutions/nic-latency-d0packetcoalescing