MAO Mesurer la latence DPC de chaque driver(Win)

Bonjour, de nombreux utilisateurs rencontrent des problèmes de latence avec leur PC (bip aigu, freeze, firewire problématique, etc.)

Je vais vous décrire une méthode permettant de connaître le temps que chaque driver passe pour la DPC (deferred procedure calls) & pour l'ISP (interrupt service routines) (et cela en traçant ces évènements dans le kernel/noyau windows)

Remarque : MAJ suite au commentaire de J-Luc :
Ce tutoriel est destiné à connaître de manière poussée l'utilisation DPC de chaque driver de votre système. Si vous voulez faire une analyse simple, vous pouvez vous utiliser le tutoriel de J-Luc :
https://fr.audiofanzine.com/mao/pedago/tutoriels/mao-mesurer-la-latence-dpc-vista-7-5339/

DPC :

Un appel de procédure différée (ou Deferred Procedure Call, abrégé "DPC") est un mécanisme utilisé sous les systèmes d'exploitation Microsoft Windows, et permettant aux tâches les plus prioritaires de reporter à plus tard l'exécution de tâches ayant un niveau de priorité inférieur. Cela permet aux pilotes de matériel ainsi qu'aux autres procédures de bas niveau d'obtenir rapidement la priorité pour leurs propres tâches, et ce, tout en attribuant un niveau de priorité d'excécution moins élevé aux processus additionnels.

Les DPC sont implémentés sous forme d'objets DPC créés et initialisés par le noyau du système d'exploitation lorsqu'un pilote ou un autre programme s'exécutant dans l'espace noyau en fait la demande. La requête DPC est donc placée en fin de la file d'attente des demandes d'appels de procédures différées. Chaque processeur dispose de sa propre file d'attentes pour les requêtes DPC. Les appels de procédures différées ont trois niveaux de priorités : basse, moyenne, et élevée. Par défaut, toutes les DPC ont une priorité moyenne. Lorsque le processeur rencontre une interruption (IRQL : Interrupt Request Level) correspondant à l'ordonnancement des tâches/DPC, il consulte la file d'attente des procédures d'appels différées et les exécute progressivement jusqu'à épuisement de la file d'attente ou jusqu'à ce qu'une autre interruption de priorité plus élevée soit rencontrée.

L'idée initiale de microsoft est de transformer ses systèmes d'exploitation non temps-réel en semi système temps réel afin notamment d'optimiser les tâches de traitement audio, vidéo, etc.

Le problème c'est que beaucoup de driver ne respecte pas le standard DPC - résultat, la gestion des priorités ne fonctionnent pas & vous vous retrouvez à avoir des pics de son aigu, cela vous forçant entre autre à augmenter le nombre de samples/buffer pour éviter cela.

Méthode:

A Installation de WDK

1)Récupérer le Windows Driver Kit (WDK) ici :https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11800

2)Installer ce kit dans le répertoire par défaut (vous trouvez les informations si besoins sur le site de Microsoft)

B Lancement de l'application

1)Lancer une fenêtre de commande : démarrer exécuter cmd      CD

2)Taper cd C:WDDK7600.16385.1toolstracingamd64 (afin de se positionner dans le répertoire contenant les outils à utiliser)

Si vous utilisez une version 32bits de windows, positionnez dans le répertoire : cd "C:WDDK7600.16385.1toolstracingi386"

3)Taper : tracelog -start -f test01.etl -dpcisr -UsePerfCounter -b 64

optionnel :Tester si des évènements sont perdus (buffer trop petit) tracelog -q

Logger Name:            NT Kernel Logger
Logger Id:              ffff
Logger Thread Id:       00000BC4
Buffer Size:            64 Kb
Maximum Buffers:        25
Minimum Buffers:        3
Number of Buffers:      25
Free Buffers:           23
Buffers Written:        571
Events Lost:            544
Log Buffers Lost:       0
Real Time Buffers Lost: 0
AgeLimit:               15
Log File Mode:          Sequential
Enabled tracing:        Process Thread Disk File ImageLoad
Log Filename:           c:Tracelogtest.etl

Si oui, augmenter la taille des buffers : tracelog -update -b 128 -max 40

C Utilisation des programmes/drivers

Le but maintenant est d'utiliser vos programmes/drivers tels qu'à l'accoutumée, et de tenter de reproduire les moments où votre son saute / lag / fait des pics aigus, etc.

D Arrêter tracelog et générer un fichier de rapport

1) tracelog -stop

2) tracerpt test01.etl -report dpcisr.html -f HTML

E Analyser le rapport html

1) Ouvrir le fichier dpcisr.html (celui-ci se trouve dans le même répertoire que le programme tracelog : C:WDDK7600.16385.1toolstracing amd64 ou i386 )

rq : le fichier généré peut aussi se trouver dans c:windowssystem32

2) Pour plus d'informations sur comment analyser le fichier aller voir le lien  : http://msdn.microsoft.com/en-us/library/ff545764%28v=vs.85%29.aspx

https://technet.microsoft.com/en-us/library/cc732700%28WS.10%29.aspx

https://developer.mozilla.org/en/Performance/Profiling_with_Xperf

--------------------------------------ANALYSE DU LOG-----------------------------

1)Nous avons ouvert le fichier dpcisr.html

2)Se positionner dans la rubrique :Répartition des temps d’exécution DPC

Ici nous obtenons l'allocation DPC par driver.

Nous devons chercher quels sont les drivers qui utilise le plus cette fonctionnalité avec une limite inférieure & supérieure élevée.

Exemple :

usbport.sys

On voit ici que le driver usbport.sys peut généré un pic élevé (entre 250 et 500) de temps d'occupation DPC mais de manière rare. (0.03%)

acpi.sys

On voit bien ici que le driver acpi.sys génère beaucoup de latence DPC (ce driver sert à la gestion de l'alimentation du système).

Il faut donc y remédier en modifiant les options d'alimentations en passant par exemple votre portable en mode performances élevées... (afin de minimiser l'impact de l'ACPI)

OU voir si d'autres personnes n'ont pas le problème avec ce driver  :

Exemple : dans google , rechercher : DPC Acpi.sys

Il faut faire de même avec les différents problèmes selon le driver (désactivation, mise à jour, etc.)

Bon courage & soyez prudent de ne pas faire n'importe quoi non plus!!