Saccades en jeu sur un PC puissant : bases de la latence DPC (et plan de correction)

Ce qu’est la latence DPC (en termes noyau simples)

Windows gère les événements matériels via des interruptions. Quand votre NIC reçoit des paquets, que votre contrôleur USB détecte un événement de périphérique, ou que votre stockage termine une I/O, le périphérique déclenche une interruption. Le CPU interrompt ce qu’il faisait, exécute une ISR (Interrupt Service Routine), puis programme en général un DPC (Deferred Procedure Call) pour effectuer le gros du travail plus tard, à une priorité d’interruption inférieure.

Les DPC existent parce que les ISR doivent rester rapides. Les ISR s’exécutent à un niveau IRQL élevé, où le système ne peut pas effectuer beaucoup d’opérations normales. L’ISR fait donc le minimum (accuser réception du matériel, enregistrer l’état) et enfile un DPC, qui s’exécute ensuite au niveau DISPATCH_LEVEL. Toujours élevé. Toujours sensible au temps. Et pouvant quand même priver d’autres travaux si il dure trop longtemps ou se répète trop souvent.

Dans le langage courant d’optimisation PC, la latence DPC signifie en pratique : « Combien de temps un travail important a-t-il dû attendre parce que quelque chose à maintenu le CPU à une priorité élevée ? » Les jeux s’en soucient parce qu’ils ont besoin de temps d’image constants. L’audio s’en soucie car les tampons doivent être remplis à l’heure. La VR s’en soucie parce que manquer des échéances provoque des nausées, pas seulement de l’irritation.

Un point clé : « latence DPC » n’est pas une métrique unique. Les outils rapportent plusieurs éléments liés :

• Temps d’exécution ISR le plus élevé : un pilote a passé trop de temps dans une ISR.
• Temps d’exécution DPC le plus élevé : le DPC d’un pilote a tourné trop longtemps.
• Latence interruption → processus : le temps entre une interruption et le retour à un thread en espace utilisateur sur le CPU.

Si vous retenez une chose : le microstutter est souvent un échec de frame pacing, et les pics DPC/ISR sont l’un des assassins de pacing les plus courants sur des machines par ailleurs puissantes.

Pourquoi un PC puissant saccade encore

Votre GPU peut s’ennuyer et votre CPU être à 20 % d’utilisation et vous pouvez quand même subir des saccades. Parce que le problème n’est pas le débit ; c’est la latence. Le débit mesure « combien de travail par seconde ». La latence, c’est « combien de temps avant que cette tâche spécifique soit traitée ». Les jeux sont des systèmes quasi temps réel qui se font passer pour des batchs. Ils fonctionnent bien jusqu’à ce qu’ils ne fonctionnent plus, et le mode d’échec est des temps d’image saccadés.

Les PC modernes sont très dépendants des interruptions. Le polling USB, les contrôleurs RGB, la gestion d’énergie Wi‑Fi, les piles Bluetooth, les améliorations audio, la télémétrie noyau, les interruptions de complétion stockage et la planification des pilotes GPU veulent tous une part. La plupart du temps, Windows arbitre correctement. Mais un pilote malveillant peut tenir la priorité élevée assez longtemps pour faire passer un budget d’image de 16,6 ms à 40 ms, puis « récupérer » comme si rien ne s’était produit.

L’autre surprise : la gestion d’énergie est un compromis. Les états C profonds, les économies agressives du package et le power gating des périphériques peuvent ajouter une latence de réveil. Cette latence apparaît sous forme de jitter. Le système n’est pas lent, il est « endormi aux mauvais moments ».

Réalité brute : le marché valorise plus les captures d’écran de FPS de pointe que le pacing d’images constant. Les problèmes DPC vivent dans la zone ennuyeuse. Donc vous devez faire votre propre exploitation.

Faits et contexte historique à répéter au travail

1. Les DPC ont été conçus pour garder les ISR courtes. C’est pourquoi un « temps DPC élevé » reflète souvent un pilote qui fait trop de travail différé au lieu de bloquer dans une ISR.
2. L’audio a rendu la latence DPC célèbre. La première vague de rapports « mon laptop craque » venait de charges audio temps réel entrant en collision avec de mauvais pilotes Wi‑Fi et ACPI.
3. Le scheduler multimédia de Windows (MMCSS) existe pour une raison. Il essaie de prioriser les threads audio/vidéo sensibles au temps, mais il ne peut pas battre une ISR/DPC qui monopolise un IRQL élevé.
4. Les interruptions de complétion stockage sont « bon marché » jusqu’à ce qu’elles ne le soient plus. Les périphériques à haut IOPS peuvent générer beaucoup d’interruptions ; si le chemin est mal réglé, vous obtenez du jitter au lieu de la vitesse.
5. HPET est devenu un remède populaire. Les gens activent/désactivent HPET parce que ça change parfois le comportement des timers, mais ce n’est pas une solution universelle et ça peut être placebo.
6. MSI (Message Signaled Interrupts) a aidé à monter en charge les interruptions. MSI/MSI‑X évite les lignes d’interruption héritées partagées et peut réduire la contention — sauf si le pilote ou le firmware est bogué.
7. La qualité du firmware ACPI varie énormément. Un petit bug BIOS dans une méthode de gestion d’énergie peut créer des tempêtes DPC périodiques. Oui, votre carte mère peut faire ça.
8. Les pilotes réseau ont une longue histoire de perturbation de la latence. Les offloads, la coalescence et les économies d’énergie gagnent en débit mais peuvent devenir des pertes de latence sur des charges interactives.
9. Les pilotes GPU sont énormes et complexes. Ils sont aussi en mode noyau, et la complexité n’est pas une stratégie d’optimisation de latence.

Symptômes et signaux : à quoi ressemble un « problème DPC »

Dans les jeux

• « Toutes les 10–60 secondes, le jeu se fige pendant une fraction de seconde. »
• Le compteur de FPS semble élevé, mais le graphique des temps d’image montre des pics.
• Les saccades s’aggravent quand vous branchez/débranchez des périphériques USB, ouvrez l’overlay, rejoignez un chat vocal ou alt‑tabbez.
• Les saccades disparaissent dans un benchmark synthétique en boucle mais apparaissent en jeu réel (parce que les interruptions et l’I/O en arrière-plan diffèrent).

Dans l’audio et le streaming

• Craquements/pop, surtout quand le Wi‑Fi est actif.
• Décalage audio lors de l’enregistrement de la partie ; le thread d’enregistrement manque ses échéances.
• Voix robotisée dans le chat vocal sous charge système.

Dans le comportement général du système

• Micro‑saccades du curseur qui coïncident avec des événements USB ou une activité de stockage.
• Pics périodiques de l’utilisation du CPU par le processus « System » sans coupable évident en espace utilisateur.
• Avertissements dans l’Observateur d’événements autour de resets de pilotes (graphismes, stockage, réseau).

Blague n°1 : la latence DPC, c’est comme une réunion qui déborde — tout le monde peut être brillant, mais l’agenda meurt quand même.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Ceci est le « vous avez une heure avant d’abandonner et d’accuser le jeu » chemin. L’objectif n’est pas de perfectionner le système ; c’est d’isoler le domaine du goulot.

Premier : confirmez que c’est un problème de latence/pacing, pas de performance brute

• Utilisez un graphique des temps d’image en jeu ou un overlay qui montre les temps d’image, pas seulement les FPS.
• Si vous voyez des pics de ~8–16 ms à 30–100+ ms, vous êtes en territoire pacing.
• Si vous voyez une montée régulière des temps d’image avec la température, vous êtes en territoire thermal/throttling. Problème différent.

Second : trouvez le plus gros coupable ISR/DPC

• Exécutez LatencyMon pendant 5–10 minutes en reproduisant la saccade.
• Triez les pilotes par temps ISR et DPC d’exécution les plus élevés.
• Cherchez les coupables familiers : pilotes réseau, pile pilote GPU, ACPI, contrôleur de stockage, bus audio, contrôleur hôte USB.

Troisième : isolez en désactivant/enlevant des classes entières de périphériques

• Testez avec Ethernet vs Wi‑Fi (ou désactivez totalement le Wi‑Fi).
• Débranchez les périphériques USB non essentiels (en particulier interfaces audio, périphériques de capture, hubs, contrôleurs RGB).
• Désactivez temporairement les overlays, les « améliorations » audio et les utilitaires système tiers.
• Passez le plan d’alimentation sur Haute performance (ou équivalent) et retestez.

Si vous pouvez faire cesser la saccade en retirant un périphérique ou en désactivant un pilote, vous avez déjà gagné. Il ne reste plus qu’à nettoyer.

Outils et méthodes : quoi utiliser, et à quoi ne pas faire confiance

LatencyMon : utile pour « qui », pas pour « pourquoi »

LatencyMon est un moyen rapide de répondre : quel pilote affiche actuellement les pires temps ISR/DPC ? Ce n’est pas un profileur de tribunal. Il échantillonne et infère. Mais pour le triage, il est excellent.

Observateur d’événements Windows : utile pour « quelque chose a reset »

Les resets de pilote (comme les événements TDR GPU) et les timeouts de stockage laissent des logs. Les logs ne racontent pas chaque microstutter, mais ils peuvent expliquer les gros incidents.

ETW/WPR/WPA : meilleur pour le « pourquoi », mais plus lent à maîtriser

Event Tracing for Windows (ETW) est le véritable substrat d’instrumentation. Windows Performance Recorder (WPR) collecte les traces ; Windows Performance Analyzer (WPA) les visualise. Si vous devez prouver une cause racine, ETW est l’outil adulte.

Vidéos « un tweak qui règle tout » : divertissement, pas exploitation

La plupart des guides de tuning massifs sont un tas de modifications du registre qui déplacent les problèmes. En termes SRE, ce sont des dérives de configuration non revues. Évitez‑les. Vous voulez des changements ciblés liés à une mesure.

Une idée paraphrasée : l’état d’esprit « dur et compétent » de Gene Kranz s’applique ici : gardez la discipline, restez calme et corrigez ce que vous pouvez prouver. (idée paraphrasée)

Tâches pratiques (avec commandes, sorties et décisions)

Voici des tâches réelles que vous pouvez exécuter sous Windows. La plupart utilisent des outils intégrés. Pour des outils tiers comme LatencyMon, la « commande » est essentiellement « lancez l’application », mais vous pouvez automatiser la collecte de preuves autour.

Task 1: Identify your Windows build and uptime (stale reboots matter)

cr0x@server:~$ systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Boot Time"
OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22631 N/A Build 22631
System Boot Time:          2/5/2026, 8:14:22 AM

Ce que cela signifie : Si vous êtes en marche depuis des semaines, vous pouvez traîner un état de pilote, des problèmes d’alimentation de périphérique ou des restes de mises à jour.

Décision : Si l’uptime est élevé et que le problème est récent, redémarrez avant d’entamer des opérations plus profondes. Oui, sérieusement.

Task 2: Check for obvious thermal/power throttling (eliminate the wrong war)

cr0x@server:~$ powercfg /energy /duration 10
Enabling tracing for 10 seconds...
Analyzing trace data...
Energy efficiency problems were found.
See C:\Windows\system32\energy-report.html for more details.

Ce que cela signifie : Ce rapport signale souvent des périphériques qui refusent de dormir, des paramètres d’alimentation mal configurés et des requêtes de résolution de timer plateforme.

Décision : Si vous voyez des requêtes répétées « Platform Timer Resolution » et que vous chassez une saccade, notez l’application/le pilote incriminé pour corrélation plus tard — pas de suppression immédiate.

Task 3: Confirm your active power plan (and stop pretending Balanced is always fine)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c  (High performance)

Ce que cela signifie : Balanced peut convenir, mais des états de repos agressifs peuvent ajouter du jitter sur certains systèmes.

Décision : Pour le diagnostic, passez en Haute performance (ou « Ultimate Performance » sur stations de travail) pour réduire les variables.

Task 4: Enumerate drivers with recent install dates (the “what changed?” list)

cr0x@server:~$ driverquery /v /fo table | findstr /I "Running"
nvlddmkm             Display                 Running   5/10/2025  NVIDIA Windows Kernel Mode Driver
rt640x64              Network                 Running   11/3/2025  Realtek PCIe GbE Family Controller
USBXHCI               USB                     Running   10/1/2025  USB xHCI Compliant Host Controller

Ce que cela signifie : Ce n’est pas une mesure de latence. C’est un inventaire. Le but est d’identifier des piles candidates (GPU, NIC, USB, audio, stockage).

Décision : Si le problème a commencé après une mise à jour de pilote, c’est votre premier test de rollback — en particulier GPU et NIC.

Task 5: Check for WHEA hardware errors (silent instability causes “weird” latency)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=17 or EventID=18 or EventID=19) and Provider[@Name='Microsoft-Windows-WHEA-Logger']]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WHEA-Logger
  Event ID: 17
  Level: Warning
  Description:
  A corrected hardware error has occurred.

Ce que cela signifie : Les erreurs corrigées (souvent PCIe) peuvent créer des retries, des blocages et des conséquences côté pilote. Pas toujours, mais suffisamment souvent pour en tenir compte.

Décision : Si des avertissements WHEA apparaissent pendant le jeu, retirez les overclocks CPU/RAM/GPU et mettez à jour le BIOS/chipset avant de chasser des tweaks DPC exotiques.

Task 6: Capture GPU driver resets and graphics errors

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=4101) and Provider[@Name='Display']]]" /c:3 /f:text
Event[0]:
  Provider Name: Display
  Event ID: 4101
  Level: Warning
  Description:
  Display driver nvlddmkm stopped responding and has successfully recovered.

Ce que cela signifie : C’est un événement « gros marteau ». Si ça arrive, vous n’avez pas un « mystère saccade », vous avez un problème de pilote/OC/stabilité d’alimentation.

Décision : Réglez la stabilité d’abord : annulez l’OC/undervolt GPU, confirmez l’alimentation/câblage PSU, réinstallez proprement le pilote GPU, puis retestez la latence.

Task 7: Check storage health quickly (timeouts feel like stutters)

cr0x@server:~$ wmic diskdrive get model,status
Model                               Status
Samsung SSD 990 PRO 2TB              OK
WDC WD10EZEX-08WN4A0                 OK

Ce que cela signifie : « OK » est superficiel. Ça ne montrera pas des problèmes de firmware NVMe limite ou des soucis de câble, mais ça repère les pannes évidentes.

Décision : Si un disque n’est pas OK, arrêtez. Réparez la santé du stockage avant de chasser la latence. Si tout est OK, continuez mais gardez le stockage dans la liste des suspects.

Task 8: Look for storport/disk timeouts in logs (classic hitch generator)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=129) and Provider[@Name='storahci']]]" /c:3 /f:text
Event[0]:
  Provider Name: storahci
  Event ID: 129
  Level: Warning
  Description:
  Reset to device, \Device\RaidPort0, was issued.

Ce que cela signifie : Les resets de stockage causent des blocages. Même si le jeu est sur un autre lecteur, l’OS peut se bloquer sur des I/O système.

Décision : Mettez à jour les pilotes chipset/stockage, vérifiez les câbles SATA, mettez à jour le firmware SSD et envisagez de déplacer les disques problématiques hors du système.

Task 9: Inspect network adapter advanced settings (interrupt moderation can be your enemy)

cr0x@server:~$ netsh interface show interface
Admin State    State          Type             Interface Name
Enabled        Connected      Dedicated        Ethernet
Enabled        Disconnected   Dedicated        Wi-Fi

Ce que cela signifie : Montre quelles interfaces sont actives. Les pilotes Wi‑Fi sont des coupables DPC fréquents quand ils sont connectés.

Décision : Pour le diagnostic, désactivez le Wi‑Fi si vous êtes en Ethernet, ou inversement. Réduisez la pile active.

Task 10: Disable Wi‑Fi temporarily (hard isolation test)

cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=disabled
Ok.

Ce que cela signifie : Vous avez retiré toute une pile de pilotes du chemin d’interruption.

Décision : Si la saccade disparaît, vous ne « optimisez pas Windows ». Vous réparez ou remplacez le pilote/matériel Wi‑Fi, ou vous ajustez ses réglages.

Task 11: Check if Game Mode is enabled (not magic, but removes some background chaos)

cr0x@server:~$ reg query "HKCU\Software\Microsoft\GameBar" /v AllowAutoGameMode
HKEY_CURRENT_USER\Software\Microsoft\GameBar
    AllowAutoGameMode    REG_DWORD    0x1

Ce que cela signifie : Game Mode peut réduire certaines activités en arrière-plan et améliorer les décisions d’ordonnancement pour les jeux.

Décision : S’il est désactivé, activez‑le pour des tests de consistance. S’il est activé et que vous avez des problèmes, ne le blâmez pas immédiatement — mesurez d’abord.

Task 12: Check HAGS (Hardware-accelerated GPU scheduling) setting

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v HwSchMode
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
    HwSchMode    REG_DWORD    0x2

Ce que cela signifie : Les valeurs varient selon les versions ; couramment, activé vs désactivé est représenté par différents DWORDs. L’important est : vous pouvez confirmer l’état.

Décision : Si vous observez des pics DPC liés au GPU, testez A/B HAGS (basculer, redémarrer, re-mesurer). Conservez l’option qui produit le moins de pics et le meilleur pacing.

Task 13: Check core isolation / memory integrity status (can affect driver behavior)

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity
    Enabled    REG_DWORD    0x1

Ce que cela signifie : L’intégrité mémoire (HVCI) améliore la sécurité mais peut modifier les caractéristiques d’exécution et la compatibilité des pilotes.

Décision : Ne la désactivez pas en premier lieu. Testez A/B seulement si les preuves pointent vers un pilote problématique et si vous acceptez le compromis de sécurité.

Task 14: Quick inventory of USB devices (remove the noisy neighbors)

cr0x@server:~$ pnputil /enum-devices /class USB | findstr /I "Device Description"
Device Description: USB Composite Device
Device Description: USB Root Hub (USB 3.0)
Device Description: USB Input Device

Ce que cela signifie : L’USB est une forêt. Cela vous aide à vous souvenir de ce qui est connecté et de ce qui peut générer des interruptions.

Décision : Si vous avez une chaîne de hubs avec audio + capture + RGB, simplifiez. Branchez directement les périphériques critiques et testez.

Task 15: Check if “System” process is spiking (kernel work visible in user tools)

cr0x@server:~$ typeperf "\Process(System)\% Processor Time" -sc 5
"(PDH-CSV 4.0)","\\DESKTOP\Process(System)\\% Processor Time"
"02/05/2026 09:12:01.123","0.000000"
"02/05/2026 09:12:02.125","3.000000"
"02/05/2026 09:12:03.126","28.000000"
"02/05/2026 09:12:04.128","4.000000"
"02/05/2026 09:12:05.129","2.000000"

Ce que cela signifie : Des pics dans le CPU du processus System peuvent être corrélés à des tempêtes ISR/DPC, des resets de stockage, des rafales réseau ou des défaillances de pilote.

Décision : Si les pics System CPU s’alignent avec les saccades, passez au traçage ETW ou isolez les piles de pilotes (NIC/USB/audio/stockage/GPU).

Task 16: Capture a baseline ETW trace with WPR (for “prove it” mode)

cr0x@server:~$ wpr -start generalprofile -filemode
WPR has started the profile.

cr0x@server:~$ wpr -stop C:\Temp\stutter.etl
WPR has stopped the profile.
The trace file has been saved as C:\Temp\stutter.etl.

Ce que cela signifie : Vous avez maintenant une trace que vous pouvez ouvrir dans Windows Performance Analyzer pour voir DPC/ISR, scheduling CPU, I/O disque, et plus.

Décision : Si LatencyMon pointe un pilote mais que vous ne pouvez pas le corriger par une mise à jour/rollback/tuning, ETW est la façon de construire un vrai dossier (ou de décider de remplacer le matériel).

Le plan de correction : pilotes, BIOS, USB, audio, réseau, GPU, stockage

1) Démarrez par la sanity des pilotes : mettre à jour, puis rétrograder si nécessaire

La plupart des problèmes de latence DPC sont des problèmes de qualité des pilotes. Votre premier geste est ennuyeux : assurez‑vous d’être sur des versions stables pour le chipset, le NIC, l’audio et le GPU. Mais « tout mettre à jour » peut aussi créer un nouveau problème. Traitez cela comme de la gestion de changement :

• Mettez à jour une pile à la fois (GPU d’abord, puis chipset, puis NIC/audio).
• Reproduisez le problème et mesurez après chaque changement.
• Si vous ne pouvez pas reproduire après un changement, arrêtez de changer. Vous avez terminé.

Oui, c’est plus lent que des mises à jour en rafale. C’est aussi la façon d’éviter de transformer votre PC en site d’archéologie judiciaire.

2) BIOS et chipset : où la latence se cache

Si LatencyMon montre ACPI.sys, Wdf01000.sys ou des pics périodiques étranges, le BIOS/firmware devient suspect. Les mises à jour BIOS incluent souvent :

• Des tables ACPI ou méthodes de gestion d’énergie améliorées.
• Des mises à jour AGESA/microcode qui affectent le comportement d’inactivité CPU.
• Des corrections de compatibilité PCIe pour certains GPU ou disques NVMe.

Mais ne commencez pas à basculer tous les réglages BIOS comme si vous désamorciez une bombe. Utilisez un petit ensemble de tests à fort impact :

• Désactivez « Global C-state control » comme test diagnostique A/B, pas comme mode permanent.
• Désactivez le spread spectrum seulement si vous chassez une instabilité d’horloge (rare).
• Assurez‑vous que XMP/EXPO est stable ; une RAM instable peut ressembler à des « saccades aléatoires ».

3) Réseau : modulation d’interruption vs latence

Les NIC sont optimisés pour le débit. Le jeu est sensible à la latence. Deux réglages courants piquent les gens :

• Interrupt Moderation : regroupe les interruptions pour réduire la charge CPU. Parfait pour les serveurs. Parfois mauvais pour les jeux/l’audio.
• Energy Efficient Ethernet / power saving : peut introduire des délais ou des négociations de lien étranges.

Stratégie de test : si désactiver le Wi‑Fi ou changer les réglages NIC fait disparaître la saccade, conservez le changement et documentez‑le. Si vous avez besoin du Wi‑Fi, essayez une autre version de pilote ou un autre adaptateur. Le matériel a le droit d’être mauvais.

4) USB : le motif du hub‑de‑l’enfer

L’USB est trompeusement complexe. Hubs, endpoints audio isochrones, souris à haute fréquence de sondage, périphériques de capture et périphériques « intelligents » peuvent générer des interruptions fréquentes. Deux tactiques fonctionnent en pratique :

• Déplacez les périphériques critiques (souris, clavier) vers des ports de carte mère, pas des hubs en face avant.
• Évitez l’empilement : n’alignez pas interface audio + webcam + capture + contrôleur RGB sur le même hub/contrôleur si possible.

Parfois le correctif est littéralement : débranchez la bande LED à 12 € qui contrôle les LEDs. Humiliant, mais efficace.

5) Audio : améliorations, mode exclusif et la victoire du « pipeline simple »

Le craquement audio est l’un des indicateurs les plus clairs d’un problème DPC. L’audio Windows fonctionne sur des échéances. Si vous manquez, vous l’entendez. Méfiez‑vous :

• Les « améliorations » (surround virtuel, suppression de bruit, couches DSP du fournisseur) qui ajoutent CPU et complexité pilote.
• Les périphériques audio virtuels tiers.
• Les casques Bluetooth (pile complexe, négociation de codec, économies d’énergie).

Si l’audio fait partie de vos symptômes, simplifiez le pipeline audio pour tester : désactivez les améliorations, retirez les périphériques inutilisés et testez avec un casque filaire basique sur un port différent.

6) GPU : pilotes stables, overlays raisonnables et cohérence d’alimentation

Les piles de pilotes GPU sont lourdes. Elles interagissent aussi avec chaque overlay et outil de capture installé. Si LatencyMon pointe les pilotes GPU (noms fréquents : dxgkrnl.sys et le module noyau du fournisseur), votre chemin de correction est :

• Réinstallation propre du pilote GPU (évitez les versions « optionnelles/bêta » pendant le dépannage).
• Désactivez les overlays un par un (Steam, Discord, GeForce Experience, outils d’enregistrement).
• Vérifiez les événements TDR (Event ID 4101). S’ils sont présents, traitez comme un problème de stabilité.
• Testez A/B HAGS et les réglages de mode de présentation.

Blague n°2 : les logiciels RGB sont la seule charge de travail qui peut baisser à la fois vos FPS et votre dignité.

7) Stockage : la saccade n’a pas besoin d’une forte utilisation disque pour être liée au disque

Le stockage peut causer des saccades de trois façons :

1. Événements timeout/reset (avertissements storahci/storport) : le système se met en pause pour récupérer un chemin de périphérique.
2. Quirks firmware/driver : bugs de firmware NVMe, états d’alimentation du contrôleur, ou pilotes bogués qui créent des pics de latence.
3. I/O en arrière‑plan : indexation, scans antivirus, écritures de cache de shaders, patchers de jeu et outils de synchronisation cloud qui concourent au mauvais moment.

Conseils pratiques sur le stockage qui tiennent en production :

• Tenez le firmware NVMe à jour, mais encore : un changement à la fois.
• Assurez‑vous que le jeu et son cache de shaders ne sont pas sur un lecteur USB défaillant.
• Surveillez les resets Event ID 129 ; si vous les voyez, arrêtez de blâmer le moteur du jeu.

8) Le trou du lapin « mode MSI » et routage des interruptions (à utiliser avec prudence)

Les Message Signaled Interrupts peuvent réduire la contention d’interruptions partagées, mais forcer le mode MSI via des outils de registre sans comprendre peut aussi casser des périphériques ou compliquer le débogage. Ma règle :

• Si vous n’êtes pas à l’aise pour revenir en arrière, ne le faites pas.
• Si vous le faites, appliquez‑le à un seul périphérique à la fois (souvent GPU ou NIC) et re‑mesurez.

Trois mini-récits d’entreprise (pourquoi ce n’est pas que du gaming)

Incident causé par une mauvaise hypothèse : « Le réseau ne peut pas affecter l’audio »

Dans une entreprise de taille moyenne avec beaucoup de réunions à distance, le support a commencé à recevoir des plaintes : « Mon casque USB crépite pendant les appels, mais seulement l’après‑midi. » Les machines étaient neuves et rapides, et l’équipe audio changeait des casques comme si c’était un problème de chaîne d’approvisionnement.

L’hypothèse erronée était subtile : ils traitaient l’audio comme un problème de couche application. Les pilotes étaient « plomberie invisible ». Le premier vrai indice est venu d’un utilisateur qui a remarqué que le craquement empirait quand de grosses synchronisations de fichiers démarraient. Un technicien a lancé un outil de latence pendant un appel et a vu des pics fréquents attribués au pilote Wi‑Fi et à un composant ACPI.

Le motif de l’après‑midi n’était pas un mystère. C’était l’environnement RF du bâtiment qui devenait plus bruyant quand plus de gens arrivaient, plus une fenêtre de synchronisation de fond planifiée. Le comportement d’interrupt moderation et d’économie d’énergie du pilote Wi‑Fi créait des rafales d’activité ISR/DPC, qui affamaient le thread audio juste assez pour manquer les échéances des tampons.

La solution n’a pas été « acheter de meilleurs casques ». Ils ont déployé une version stable du pilote Wi‑Fi, désactivé un réglage d’économie d’énergie spécifique dans la politique de l’adaptateur et déplacé les fenêtres de synchronisation lourdes hors des heures de réunion. Le craquement a disparu. Le pipeline audio était correct ; c’était le pipeline d’interruptions qui ne l’était pas.

Une optimisation qui s’est retournée contre eux : « Activons toutes les fonctions offload »

Dans un autre environnement — imaginez des stations de travail d’ingénierie et de la virtualisation locale — quelqu’un a décidé « d’optimiser les performances réseau » en activant un ensemble de fonctions NIC sur la flotte. L’objectif était légitime : réduire l’utilisation CPU durant de gros transferts et améliorer le débit pour les builds et images VM.

Le débit s’est amélioré sur le papier. L’utilisation CPU a baissé dans le tableau de bord. Tout le monde s’est félicité et est passé à autre chose, car les tableaux de bord aiment les moyennes.

Puis sont venues les plaintes : latence interactive dans les sessions RDP, saccades pendant des démos, et glitches audio pendant le partage d’écran. Les machines étaient toujours « rapides », mais l’expérience humaine avait diminué. Les charges sensibles à la latence payaient le prix du batching et de la coalescence.

Ils ont rollbacké un sous‑ensemble de réglages : la modulation d’interruption est devenue « adaptive », certains offloads ont été désactivés pour des adaptateurs spécifiques, et l’économie d’énergie a été adoucie. Le débit est resté suffisamment bon et l’expérience interactive est revenue. La leçon est classique SRE : optimiser une métrique sans SLO de latence est la recette pour créer une douleur utilisateur invisible.

Une pratique ennuyeuse mais correcte qui a sauvé la mise : « Contrôle des changements et baselines »

Les machines de build d’un studio de jeux servaient aussi de rigs de capture pour les images marketing. Toutes les quelques semaines, quelqu’un mettait à jour « les pilotes qui semblent vieux », parce que ces rigs n’étaient pas considérés comme production. Puis, juste avant une deadline, les sessions de capture commençaient à montrer des pics de pacing et des frames audio perdues.

Un ingénieur a finalement imposé une règle ennuyeuse : chaque rig a une image de base, un manifeste de pilotes et un journal des changements. Les mises à jour n’ont lieu que lors d’une fenêtre de maintenance, un composant à la fois, avec un test de capture reproductible et une trace sauvegardée.

La fois suivante où une saccade est apparue, il a fallu moins d’une heure pour isoler : un pilote de périphérique de capture USB récemment mis à jour générait des temps DPC plus élevés sous certaines résolutions. Ils ont rollbacké le pilote, envoyé un ticket au fournisseur avec une trace attachée, et respecté la deadline.

Ce n’était pas de l’héroïsme. C’était la discipline peu sexy des baselines. En production, l’ennuyeux est souvent synonyme de fiable.

Erreurs fréquentes : symptôme → cause racine → fix

• Symptôme : « Saccades toutes les quelques secondes, surtout en ligne. »
  Cause racine : Pics DPC du pilote NIC/Wi‑Fi ; interrupt moderation/économie d’énergie ; version de pilote boguée.
  Fix : Désactivez le Wi‑Fi pour tester ; mettez à jour ou restaurez le pilote NIC ; ajustez l’interrupt moderation ; désactivez EEE/power saving pour le diagnostic.
• Symptôme : « L’audio crépite en jouant ou en appel. »
  Cause racine : DPC starvation due au Wi‑Fi, USB ou ACPI ; améliorations audio ajoutant du traitement ; tampon trop petit pour un système instable.
  Fix : Simplifiez la chaîne audio (désactivez les améliorations), déplacez le périphérique sur un autre contrôleur USB, testez Ethernet filaire, mettez à jour chipset/BIOS.
• Symptôme : « Gros hitch aléatoire, puis tout revient normal. »
  Cause racine : Reset stockage (Event ID 129) ou TDR GPU (Event ID 4101).
  Fix : Pour le stockage : firmware, câbles, pilotes de contrôleur. Pour le GPU : annulez OC/undervolt, réinstallez proprement le pilote, vérifiez l’alimentation.
• Symptôme : « Saccades seulement avec beaucoup de périphériques USB connectés. »
  Cause racine : Surcharge du hub/contrôleur USB ; pilote périphérique problématique ; contention d’appareils isochrones.
  Fix : Réduisez la chaîne de hubs, connectez directement les périphériques critiques, retirez les suites de contrôle vendor, mettez à jour pilotes contrôleur USB/chipset.
• Symptôme : « Les saccades ont commencé après une mise à jour BIOS. »
  Cause racine : Changements de valeurs par défaut de gestion d’énergie ; entraînement mémoire instable ; comportement PCIe altéré.
  Fix : Réinitialisez le BIOS aux valeurs par défaut, réappliquez seulement les réglages nécessaires, confirmez la stabilité RAM, envisagez un rollback BIOS si possible.
• Symptôme : « LatencyMon montre ACPI.sys ou Wdf01000.sys. »
  Cause racine : Souvent un proxy : un pilote device interagissant avec ACPI, la gestion d’énergie ou un driver framework provoquant des blocages.
  Fix : Corrélez avec des changements de périphérique (USB/NIC), mettez à jour BIOS/chipset, désactivez les C‑states profonds en test, puis isolez les périphériques en les désactivant.
• Symptôme : « Saccades seulement lors de l’enregistrement/streaming. »
  Cause racine : Hooks overlay/capture, pression sur la planification GPU, écritures stockage, pics DPC du périphérique de capture USB.
  Fix : Testez sans overlays, changez la méthode de capture, déplacez l’enregistrement sur un autre lecteur, mettez à jour les pilotes du périphérique de capture, trace ETW pour confirmer.
• Symptôme : « Tout va bien dans les benchmarks mais pas en jeu réel. »
  Cause racine : Les benchmarks ne déclenchent pas les mêmes interruptions (voix, réseau, anti‑cheat, écritures de cache de shaders).
  Fix : Mesurez en reproduisant le scénario réel ; isolez en désactivant réseau/USB/overlays ; utilisez une trace WPR.

Listes de vérification / plan pas à pas

Checklist A: 30-minute triage (minimum viable sanity)

1. Redémarrez. Négociez pas avec cette étape.
2. Passez le plan d’alimentation en Haute performance pour les tests.
3. Désactivez les overlays (un clic chacun) et retestez.
4. Déconnectez les périphériques USB non essentiels et retestez.
5. Désactivez le Wi‑Fi (ou l’Ethernet) et retestez avec un seul chemin réseau.
6. Lancez LatencyMon pendant 10 minutes en reproduisant la saccade ; notez les 3 principaux coupables ISR/DPC.
7. Vérifiez l’Observateur d’événements pour GPU TDR (4101), avertissements WHEA (17/18/19) et resets storport/storahci (129).

Checklist B: Fix progression (change control for a single PC)

1. Faites une baseline : enregistrez les versions pilotes (GPU/NIC/chipset), la version BIOS, la build Windows.
2. Stabilité d’abord : retirez overclocks/undervolts ; confirmez que WHEA est silencieux sous charge.
3. Mettez à jour BIOS/chipset si ACPI/drivers framework apparaissent et que vous êtes en retard de plusieurs versions.
4. GPU A/B : réinstallation propre, puis test HAGS on/off, puis test des overlays.
5. Réseau : choisissez un adaptateur, une version de pilote ; ajustez l’interrupt moderation si nécessaire.
6. Simplification USB : réorganisez ports et hubs ; retirez temporairement les suites de contrôle vendor.
7. Validation stockage : cherchez resets/timeouts ; mettez à jour firmware SSD ; déplacez jeu/enregistrement hors des dispositifs suspects.
8. Prouvez avec ETW : si vous êtes toujours bloqué, capturez une trace et identifiez le goulot d’ordonnancement.

Checklist C: “Don’t do this” list (how people waste days)

• Ne pas appliquer 30 tweaks du registre d’une vidéo puis demander lequel a aidé.
• Ne pas désactiver les fonctions de sécurité en premier. Corrigez pilotes et stabilité d’abord.
• Ne pas changer les réglages BIOS au hasard. Testez A/B une variable et mesurez.
• Ne blâmez pas le jeu avant d’avoir vérifié que le système ne journalise pas de resets matériel ou pilote.

FAQ

1) Quel est un mauvais chiffre de latence DPC ?

Il n’y a pas de seuil universel parce que les charges diffèrent. Pour le jeu/l’audio, vous vous souciez des pics. Un système qui reste bas la plupart du temps mais qui monte en pic à des temps d’exécution DPC/ISR multi‑millisecondes peut quand même saccader.

2) Pourquoi LatencyMon incrimine souvent ACPI.sys ?

Parce qu’ACPI est impliqué dans la gestion d’énergie et le contrôle des périphériques. ACPI.sys peut être le messager, pas le criminel. Cherchez ce qui se corrèle : événements de gestion d’énergie des périphériques, pics périodiques, et quelles piles de périphériques ont changé récemment.

3) Le stockage peut‑il vraiment causer du microstutter même si l’utilisation disque est faible ?

Oui. Un événement timeout/reset concerne la latence, pas l’utilisation. Un seul reset de chemin peut bloquer des threads en attente de complétion I/O, même si le MB/s total est minime.

4) Dois‑je désactiver les C‑states ?

Comme test diagnostique A/B, oui — parfois. Comme optimisation permanente « gaming », généralement non. Ça peut augmenter la consommation au repos et la chaleur. Utilisez‑le pour confirmer que la latence de réveil des états d’alimentation est impliquée, puis cherchez une mise à jour firmware ou un meilleur réglage.

5) HPET activé/désactivé est‑ce la solution ?

Parfois ça change suffisamment le comportement des timers pour modifier les symptômes, mais ce n’est pas une solution fiable à la racine. Si basculer HPET aide, considérez‑le comme un indice que le timing/le scheduling compte, puis creusez du côté des pilotes et de la gestion d’énergie.

6) Pourquoi les overlays et outils de capture causent‑ils des saccades ?

Ils hookent les pipelines de rendu, planifient du travail GPU/CPU et ajoutent des composants pilotes. S’ils sont mal conçus ou en conflit avec un anti‑cheat ou la planification GPU, ils peuvent ajouter du jitter. Désactivez‑les pour isoler.

7) Mon PC ne saccade que quand le Wi‑Fi est activé. Quelle est la vraie solution ?

D’abord, confirmez en désactivant le Wi‑Fi et retestant. Ensuite : essayez une autre version du pilote, désactivez l’économie d’énergie de l’adaptateur, ajustez l’interrupt moderation, ou remplacez l’adaptateur. Si vous utilisez une clé Wi‑Fi USB bon marché, c’est un signe.

8) Le plan d’alimentation « Haute performance » aide‑t‑il toujours ?

Il réduit certaines transitions d’économie d’énergie et peut réduire le jitter, donc il aide souvent pour le diagnostic. Pour un usage quotidien, vous pouvez revenir à Balanced une fois l’origine corrigée, ou garder un plan par jeu si vous préférez la consistance.

9) Est‑il sûr de désinstaller des pilotes qui apparaissent dans LatencyMon au hasard ?

Non. « Apparaît » n’est pas « sûr à supprimer ». Préférez désactiver temporairement des périphériques, restaurer des pilotes ou mettre à jour depuis l’OEM/fournisseur chipset. Si vous retirez la mauvaise chose, vous pouvez casser le sommeil, l’audio, le réseau ou le stockage.

10) Quand dois‑je utiliser ETW (WPR/WPA) plutôt que LatencyMon ?

Quand vous avez besoin de preuve, quand LatencyMon pointe quelque chose d’ambigu, ou quand les changements ne font rien. ETW peut montrer l’ordonnancement CPU, l’I/O disque, les timelines DPC/ISR et la corrélation avec la fenêtre de saccade.

Conclusion : prochaines étapes qui ne gâcheront pas votre week-end

Les saccades sur un PC puissant ne sont généralement pas un problème de puissance brute. C’est un problème d’échéance. Quelque chose en mode noyau maintient le CPU à une priorité élevée juste assez longtemps pour ruiner le pacing d’images. Votre travail est d’identifier quelle pile : réseau, USB, audio, GPU, stockage ou gestion d’énergie firmware.

Faites cela ensuite :

1. Reproduisez la saccade à la demande (même scène en jeu, mêmes réglages, mêmes périphériques connectés).
2. Lancez LatencyMon pendant 10 minutes lors de la reproduction et notez les principaux coupables.
3. Vérifiez l’Observateur d’événements pour resets GPU, avertissements WHEA et resets stockage.
4. Isolez en désactivant le Wi‑Fi, en débranchant les périphériques USB et en désactivant les overlays — un changement à la fois.
5. Appliquez des correctifs ciblés : rollback/mise à jour pilote, mise à jour BIOS/chipset, réglage du plan d’alimentation, réorganisation topology USB.
6. Si vous êtes toujours bloqué, capturez une trace ETW avec WPR et analysez DPC/ISR + ordonnancement CPU autour du moment de la saccade.

Si vous traitez ceci comme une réponse d’incident plutôt que comme de la superstition, vous le réparerez — et vous saurez exactement ce que vous avez réparé. Voilà la différence entre « optimisé » et « stable ».