Introduction
Afin de bien comprendre de quoi nous parlons, je vous invite à lire l'article suivant : Les interruptions matérielles ou IRQ dans Windows.
Ce dernier explique notamment ce que sont les IRQ et leur utilité.
Autre précision : MSI n'a rien à voir avec la marque du constructeur MSI.
MSI signifie "Message Signaled Interrupts"
Ce n'est pas nouveau mais cela faisait un petit bout de temps que je voulais indiquer la procédure (manque de temps, flemme, digestion de la galette des rois etc :-)
Dans le menu du gestionnaire de périphériques, et en choisissant dans le menu "Affichage" ---> Par type de connexion, on peut voir que sous une machine relativement ancienne sous Win,7, j'ai pratiquement la majorité des périphériques qui ne sont pas sur une IRQ (en bleu) mais sur MSI (en rouge) parce que j'ai procédé à la manipulation
Le fait de voir un nombre en apparence négatif avant le nom du périphérique indique que celui-ci est en mode MSI
Les chiffres affichés dans la fenêtre ne sont pas les clés. Ils ne font que présenter les numéros IRQ sous forme hexadécimale.
Évidemment il en est de même sous WIN10 ou 11 mais avec 2 cas : Un hardware relativement ancien ou presque rien n'est activé, ou très récent, où certains pilotes sont écrits pour activer le mode MSI
Précautions avant de suivre ce tuto
! | L'opération est globalement sans risques mais... Dans de TRES rares cas (surtout avec les OS présentant à la base des instabilités, pilotes finis à la truelle, et matériels bas de gamme ou ancien avec les pilotes non adaptés), l'activation MSI, si cela ne fonctionne pas, amène le risque, au pire de se retrouver à réinstaller Windows (cas de la carte graphique et de l'USB par ex et surtout SATA dont et surtout sur les ordis portables ) ou au mieux à repartir sur un point de restauration Néanmoins je n'ai JAMAIS constaté ce problème. Il faut juste prendre cela comme un avertissement, tout comme le fait de modifier le registre présente des risques, etc, sans compter que le risque zéro n'existe pas |
Dans la majorité des cas, cependant (et heureusement) le flag MSI est tout simplement ignoré
(voir copie écran en deuxième partie)
Le mieux étant d'effectuer une sauvegarde de votre disque C avant les manipulations
Ensuite tester un par un les passage IRQ en MSI, et redémarrer (en cas de problème cela permet d'isoler la cause).
Pour se faire, vous pouvez suivre les articles :
- Créer une image système de Windows 11
- Créer une image système de Windows 10
- Créer une image système de Windows 7
En plus suivant les configurations cela peut ou ne pas fonctionner (carte mère trop anciennes avec pilotes propriétaires, surtout si vous touchez aux contrôleurs SATA et cartes vidéo)
La règle imposée n'est pas matérielle, mais liés aux pilotes compatibles ou pas MSI
Concernant Microsoft, cela fonctionne depuis Windows VISTA (mais pas XP et Windows serveur 2003) et bien sûr pour Windows 10
Cela présente un intérêt et peut apporter une solution à vos problèmes, surtout si vous avez plusieurs périphériques sur la même IRQ
Autrefois on parlait de conflits d'IRQ. De nos jours, on parle de partages IRQ (l'IRQ steering est censée résoudre les problèmes de conflits d'IRQ). Cela ne fige plus au démarrage ou plante (normalement) mais cela introduit une latence, et surtout des petits problèmes au quotidien assez irritants
! | Je déconseille la manipulation sur les ordis portables (du fait des pilotes qui peuvent être modifiés ou propriétaires de la marque) même si certains ont passé l'épreuve avec succès |
Cela ne semble pas fonctionner sur certaines cartes ASUS (mais cela ne fait pas planter le système) pour ceux qui ont des craquements audios et de la latence, notamment sur les modèle Z97 et ROG (donc carte mère axée jeux)
La solution étant d'aller dans le BIOS et configurer le PCI-E sur Gen2, puis ensuite aller sur Configuration de l'agent système et PCI-EX16 Link 1 vers Gen2.
Idem pour certaines cartes sons. Une soundblaster peut ou pas accepter la manipulation mais si cela est accepté, il a été vu des plantages avec l'usage de l'interface de gestion/préférences. Même soucis avec les cartes Sonar et certaines cartes son ASUS, qui ne l'accepteront pas
Avec les Realtek et VIA il n'y a pas de problèmes
Cela ne peut pas fonctionner non plus sur le chipset amd sb950 du fait d'un bug non corrigé sur ce chipset
Sur les puces réseau Killer, cela peut être la catastrophe (du reste il vaut mieux n'installer QUE les pilotes avec ces cartes) tout le reste à un impact négatif sur le sytème
A noter que les SSD de type NVMe doivent être livrées maintenant avec des pilotes qui activent le mode MSI par défaut
(Copie écran du programme cité en lien un peu plus bas)
Pourquoi passer en MSI ?
QUEL EST LE BUT de cette manipulation ? (plus détaillé)
Cela permet de basculer l'IRQ individuelle en utilisant des périphériques d'interruptions héritées à latence élevée vers des MSI (cela s'affichera sous la forme IRQ -1 en cas de succès)
Néanmoins les dernières moutures de Windows traitent mieux qu'avant le partage d'IRQ qui était une source de problèmes.
Cependant dans les faits, des problèmes persistent, surtout pour ceux qui traitent le son ou les joueurs
Avec le mode MSI, certains sont passés à latence audio très faible (aller-retour de 5 ms contre 90 à 150ms auparavant) sur une station de travail audio avec plus d'une centaine de plugins audio, qui travaillent en temps réel.
___________________________________________________________
Idéalement et accessoirement (et cela peut servir pour les jeux) ceux qui traitent le son, en profitent pour faire la manipulation suivante dans la base de registre
Arrêtez et désactivez le service" Multimedia Class Scheduler "
Exécutez regedit et accédez à "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Audiosrv"
Double-cliquez sur l'entrée "DependOnService" et supprimez la ligne avec "MMCSS" de la zone de texte.
Redémarrez
___________________________________________________
Il faut savoir quand même que cette gestion MSI, (voir les liens doc plus bas) est en fait la méthode PCI-Express «native» de signalisation d’interruptions, qui permet plus d'interruptions par matériel et apportent surtout une faible latence pour la gestion des interruptions.
Les MSI ont donc une latence bien inférieure, et cela peut régler les problèmes de DPC latency (au sens global), de craquements audios pour ceux qui utilisent du câble HDMI etc mais pas que...
Précision :
Le temps d'exécution DPC ne dépend pas du mode IRQ du périphérique, car la routine DPC effectue le travail réel du pilote, qui est toujours identique - pour traiter les requêtes vidéo, audio et réseau.
Le temps d'exécution de la routine ISR le plus élevé peut dépendre du mode IRQ du périphérique, c'est-à-dire la routine qui gère les demandes d'interruption ...
On peut se servir de LatencyMon pour avoir une vision globale de la chose
LatencyMon ne montre pas les latences des pilotes. Il affiche les temps d'exécution de la routine DPC dans l'onglet "Pilotes" (avec le nombre ISR et DPC). Et il affiche le temps d'exécution ISR le plus élevé (ainsi que le nom du pilote avec le temps d'exécution de routine ISR le plus élevé) dans l'onglet "Stats"
MSI contre le stuttering et latence DPC
POUR FAIRE SIMPLE, CONCRETEMENT, QU'EST CE QUE CELA APPORTE ?
Lors de fortes charges, si vous utilisez un outil comme LatencyMon, vous verrez un niveau de latences stables, presque deux fois plus bas qu'avant la manipulation, et un stuttering habituel à forte charge qui disparait lors d'usage de différents programmes, qui vont de l'usage de la carte graphique, mais aussi de programmes tiers comme Skype, twitch, ... au lecteur MP3, en passant par VisualStudio, VMWare, et.. sous certains jeux
Vous y gagnerez donc en souplesse et fluidité du fait d'une amélioration du temps de réponse global du fait qu'en mode MSI, les interruptions des périphériques sont traitées plus rapidement par la CPU (par le noyau du système d'exploitation).
Donc, en termes simples, le mode MSI offre une meilleure communication entre le processeur et les périphériques.
MSI et les cartes réseaux
Pour une carte réseau il est dit
"Les cartes réseau prenant en charge MSI / MSI-X peuvent cibler leurs interruptions sur des processeurs spécifiques. Si les adaptateurs prennent également en charge RSS, un processeur peut être dédié au traitement des interruptions et des DPC pour une connexion TCP donnée. Cela préserve la localisation en cache des structures TCP et améliore considérablement les performances."
Ce qu'il faut passer en priorité en MSI ce sont les cartes graphiques, réseaux, contrôleurs SATA, contrôleurs USB. Le reste est annexe est l'impact est moindre
L'USB 2 est une des sources d'interruption de masse.
Les ports USB 1 et 2 continuent à rechercher des données même sans périphériques connectés.
L'USB 3.0 (d'après les spécifications) ne le fait pas et interroge uniquement en cas de besoin.
Malheureusement, autant vous pourrez passer l'USB3 en mode MSI, autant il est conseillé de ne pas toucher à l'USB2, parce que Microsoft n'a jamais jugé la possibilité de les passer en mode MSI.
Il faut donc se rappler que "SEULS" les contrôleurs USB3 sont capables de passer en mode MSI.
Donc pour l'USB 2: Ne pas toucher
_______________________________
MSI et les cartes graphiques NVidia
Lorsqu'on a une carte video NVIDIA on peut se demander pourquoi cela ne se fait pas tout seul lors de l'installation des pilotes, d'autant plus que les GPU prennent déjà en charge MSI depuis bien longtemps
Bizarrement c'est le cas pour certains ordinateurs portables, mais Nvidia a été fortement échaudé avec les chipsets nForce qui ont une implémentation MSI buguée
Voici ce que raconte NVIDIA (on trouve l'explication non pas pour les pilotes windows mais Linux)
http://us.download.nvidia.com/XFree86/L ... ssues.html
"Le pilote ne parvient pas à s'initialiser lorsque les interruptions MSI sont activées
Le pilote Linux NVIDIA utilise les interruptions signalées par message (MSI) par défaut. Cela offre des avantages en termes de compatibilité et d'évolutivité, principalement en raison de l'évitement du partage d'IRQ.
On a constaté que certains systèmes rencontraient des problèmes de prise en charge de MSI, alors qu’ils fonctionnaient parfaitement avec des interruptions de fil virtuelles. Ces problèmes se traduisent par une incapacité à démarrer X avec le pilote NVIDIA ou par des échecs d'initialisation CUDA. Le pilote NVIDIA signalera alors une erreur indiquant que le module de noyau NVIDIA ne semble pas recevoir les interruptions générées par le GPU.
Des problèmes ont également été constatés lors de la suspension / reprise lorsque MSI est activé. Tous les problèmes connus ont été corrigés, mais si vous rencontrez des problèmes de suspension / reprise que vous n'aviez pas vus avec des pilotes précédents, la désactivation de MSI peut vous aider.
NVIDIA travaille sur une solution à long terme pour améliorer la compatibilité immédiate des pilotes avec les configurations système qui ne prennent pas totalement en charge MSI.
Les interruptions MSI peuvent être désactivées via le paramètre de module de noyau NVIDIA "NVreg_EnableMSI = 0". Cela peut être défini sur la ligne de commande lors du chargement du module, ou de manière plus appropriée via les fichiers de configuration du module du noyau de votre distribution (tels que ceux situés sous /etc/modprobe.d/).
___________________________________________
Bref, NVIDIA ne peut pas se permettre d'activer le flag MSI lors de l'installation, sauf si tout le monde dispose d'une carte mère récente, et qui suit les normes (là aussi on se demande ce qu'ASUS fait avec certaines carte mère récentes pour que cela ne fonctionne pas). Les barebones peuvent également poser problème
Ils ont déjà assez de soucis avec les bugs des pilotes
CONTRAINTE AVEC LE PILOTE GRAPHIQUE NVIDIA
Le seul problème c'est qu'à chaque installation des pilotes graphiques il faut refaire la manipulation de l'IRQ vers MSI car le fichier d'installation de NVIDIA ne prends pas en compte cette donnée et écrase les données inscrites dans le registre
Pour ceux qui disposent d'une carte AMD, ceux ci ont simplement activé MSI par défaut pour leurs propres GPU.
Si vos pilotes INTEL, sont à jour, "normalement" vos pilotes SATA AHCI pour Windows mettent actuellement SATA en mode MSI (mais ce n'est pas toujours le cas)
_____________________________________________________________
Maintenant après l'aspect théorique et les explications sommaires (si si j'ai simplifié :-) mais il faut savoir ce que c'est pour comprendre ce que cela implique
Comment passer en MSI ?
COMMENT PROCEDER ?
On peut s'amuser à changer, après avoir identifié les périphériques, avec la base de registre (si j'ai le temps j'indiquerai la procédure)
Néanmoins ce genre de manipulations peut être source d'erreurs et comme un programme permet de gérer cela autant s'en servir
Edit du 25/04/2021 le lien ci dessous ne fonctionne plus
https://github.com/CHEF-KOCH/MSI-utility/releases
L'auteur à tout mis sur Mediafire (liens provisoires avant d'être installés sur le serveur Malekal)
Rappel : Fichier sans installation à excuter en mode administrateur
---------------------------------
V2 https://www.mediafire.com/file/2kkkvko7 ... 2.zip/file
MD5 hash for zip-file: 566495427F95F14D327AA4C9634CBEF6
Change log:
Code : Tout sélectionner
- New devices grid layout with 6 columns - name, irq, msi, limit, max limit, supported modes, interrupt priority, where msi is a checkbox column (for the MsiSupported registry value), limit is a textbox column (for the MessageNumberLimit registry value) which accepts either empty string or integer value in range of 0..2048 (where 0 has the same meaning as empty string - no limit), interrupt priority is combobox column to select the priority of interrupts.
- Utility is built with .Net Framework 4.5.https://www.mediafire.com/file/ewpy1p0r ... 3.zip/file
MD5 hash for zip-file: F7A7AD46A2F3EFB37AC9B95D8DCCDE2E
Change log:
Code : Tout sélectionner
- showing multiple IRQs for device (previous version showed only first of multiple IRQs);
- extending the details pane (under the grid) for the selected device to show more properties - PNP and PCI ones;
- replacing WMI with Setup API for retrieving device properties - so all info should be available on Win7/Win8 rigs;
- replacing registry names of devices with normal PNP display names from Setup API;
- adding the ability to launch the registry editor with selected device instance by double click on the device.
L'auteur précise bien que "Cela ne peut être utile qu’à l’étape ISR de la gestion des interruptions. Cela peut être considérable pour l'utilisation du serveur (avec plusieurs cartes réseau, périphériques de stockage et charge de réseau et de données importante). Mais pour la maison, l’amélioration est minime. Cela peut évidemment résoudre les petits problèmes de sons, de latence, permettre une meilleure fluidité etc mais personne n'y gagne en performances "visibles" surtout avec les machines puissantes de ces dernières années
Le principe est simple : Il suffit de cocher la case MSI pour passer d'IRQ en MSI. Comme déjà indiqué dans l'avertissement, il faut procéder périphérique par périphérique en ne cochant qu'une case à la fois et en rebootant (je conseille de désactiver le redémarrage rapide source de problème)
J'ai mis une copie écran de ce qui peut se passer sur certaines configurations
- Dans la colonne de gauche vous avez le nom du périphérique
- Ensuite l'IRQ. Le numéro négatif c'est juste un numéro séquentiel. Lorsque le système d’initialisation initialise les périphériques, le numéro IRQ est sélectionné dans le groupe des périphériques libre.
Si le périphérique dans le gestionnaire de périphériques (ou dans l'utilitaire) affiche un numéro IRQ positif, avec la case MSI cochée, il utilise le mode Line Based hérité.
Si le périphérique dans le gestionnaire de périphériques affiche un nombre IRQ négatif, il utilise le mode MSI / MSI-X.
- Dans la colonne MSI, si tout se passe bien cela doit être coché
Si il apparait une valeur négative mais non coché cela signifie simplement que les périphériques n'ont pas de clés / valeurs de registre associées à MSI, mais fonctionnent en mode MSI malgré cela.
- La colonne "limite maximale" indique le nombre maximal d'interruptions de message prises en charge par le périphérique dans le matériel.
La colonne "modes pris en charge" indique les modes d'interruption pris en charge par le périphérique dans le matériel.
Sur les anciennes versions de Windows, cette colonne doit être masquée
Les deux colonnes tirent leurs valeurs de WMI. Si quelque chose ne va pas avec WMI, elles doivent rester vides (pas d'imapct négatif)
Il est déconseillé de modifier la valeur "limit"
Lorsque la valeur de la colonne "limite" n'est pas spécifiée, cela signifie simplement que les développeurs de pilotes de périphérique n'ont pas défini de limite spécifique pour le nombre de messages par périphérique.
On ne sait donc pas si le matériel utilise (ou peut utiliser) plusieurs messages simultanément (seul le fabricant du matériel et peut être développeur du pilote le savent)
Pour l'anecdote, chez Qualcomm avec leur carte Killer, depuis le rachat, ils ne savent .. Rien :-)
Lorsque la valeur de la colonne "limite" (Message Number Limit) est spécifiée, cela signifie simplement que les développeurs de pilotes de périphérique ont défini une limite spécifique pour les messages par périphérique.
Cela ne veut pas dire que que le périphérique utilise plusieurs messages simultanément seulement que du point de vue matériel il peut le faire. Et cette limite spécifique prédéfinie par le fabricant du périphérique est un paramètre totalement intrinsèque destiné à être lu uniquement par le sous-système plug-and-play du noyau du système d'exploitation.
Pour PCI 2.2, MessageNumberLimit doit être 1, 2, 4, 8 ou 16. Pour PCI 3.0, MessageNumberLimit peut être un nombre quelconque allant jusqu'à 2 048.
Les cartes réseaux actuelles utilisent généralement plusieurs MSI pour une carte, pour la logique "un MSI par CPU (cœur)" - pour augmenter le débit. La fonctionnalité s'appelle Receive Side Scaling et est basée sur MSI, ils l'appellent NDIS MSI-X
Dans les faits, pour la carte réseau, certains en baissant cette valeur ont vu leur débit augmenter et surtout ne plus planter (la aussi cela peut être la faute du dev des pilotes qui a mis une valeur générique liée au matériel alors qu'on sait que certains fabricants de carte mère peuvent implémenter des matériels castrés ou modifiés à leur demande : Cas des ordis portables par ex, ou pas le passé avec des cartes sonores Realtek en beta
Sur la partie technique il indique :
"Les interruptions sont traitées par deux routines - ISR et DPC. ISR est déclenché en premier, et puisqu'il bloque complètement le processeur (cœur), il doit être aussi court que possible. Le mode MSI lui permet de programmer une seconde routine (DPC) pratiquement instantanément (fournissant toutes les informations nécessaires sur l'interruption). Mais en mode ligne, l’ISR doit demander à l’appareil de nouveau des informations supplémentaires, et ce, uniquement après cela, il peut programmer le DPC.
De plus, plusieurs périphériques fonctionnant en mode ligne peuvent partager le même numéro d'IRQ. Dans ce cas, les ISR des deux périphériques doivent reconnaître les périphériques déclenchés en interruption.
En mode MSI, il n'y a pas de partage d'IRQ - bonus supplémentaire. Mais la partie DPC de la gestion des interruptions ne dépend pas des modes MSI / Ligne. La routine DPC devrait effectuer un travail réel sur l’interruption. Et nous ne pouvons pas influencer cette partie. Seulement en choisissant la version des pilotes.
Dans les temps anciens, les interruptions étaient gérées par une routine ISR, ce qui était la raison d’une longue période de non-réponse / hoquets / bégaiement. Ensuite, les développeurs divisent une routine en composants ISR et DPC. La partie ISR est exécutée à un niveau de priorité très élevé, tandis que la partie DPC est exécutée à un niveau de priorité inférieur, permettant d'exécuter certaines tâches en parallèle."
Pour les cartes graphiques NVIDIA il existe cet utilitaire (mais qui ne fait QUE cela) -j(ai testé sous Win7 et Win10 avec une MSI 970 et une 1080Ti et cela fonctionne bien)
https://github.com/TechtonicSoftware/MS ... ptEnabler
Les limites de l'utilisation de MSI
EST CE UNE SOLUTION MIRACLE ?
NON
Tout comme le HPET, la désactivation du core parking, etc, cela peut être bénéfique (au sens où l'on voit un gain).. ou pas suivant les configurations matérielles, l'OS utilisé et ce que l'on fait avec son PC
Sur une machine puissante le gain "visuel" sera évidemment moindre
Cela "peut" cependant améliorer les performances et résoudre les problèmes d'IRQ partagés si ils sont mal gérés avec les conséquences déjà décrites au début de l'article
Sous Win 7 par ex, suivant les carte mères, la ligne du HPET est visible dans le bios, pour d'autres non, mais dans ce dernier cas le HPET est activé. Seulement il ne l'est pas sous Windows, et si cela est fait certains auront du stuttering, surtout en SLI, et d'autres pas etc
On considère que sur les plates-formes matérielles modernes, il vaut mieux laisser Windows décider par lui-même.(ce que fait Win10 avec le matériel récent)
D'un point de vue théorique, pour toutes ces manipulations, cela ne peut être QUE bénéfique de toutes les façons
Voir :
https://www.malekal.com/optimisation-bo ... iver_HPET"
https://www.malekal.com/lantence-dpc-ve ... -windows/
Pour les jeux c'est... selon avec parfois une petite perte de FPS (pour le HPET par ex) mais au bénéfice de la stabilité et surtout une meilleure réactivité (mode MSI, HPET, ...)
Sous Win10 le HPET est activé par défaut, mais à priori partiellement (on se demande pourquoi) ou alors Microsoft veut une utilisation TSC+HPET
C'est visible avec le "Timer resolution" ou WIn10 force les jeux et applications à s'exécuter en 0.5ms au lieu de 1.0ms
Idem pour les matériels et pilotes qui n'utilisent pas le MSI au lieu de l'IRQ, alors que tout cela est définie depuis la norme PCI 2.2
Bref tout comme le HPET et le reste, la manipulation IRQ vers MSI est à tester, tout en étant conscient que ce n'est pas LA solution à tous les problèmes (qui peuvent avoir d'autres causes )
Je le répète, mais Il ne faut pas prendre toutes ces manipulations comme un moyen de gagner des FPS ! (on peut même parfois en perdre) mais comme un moyen d'avoir un PC plus réactif, mieux à même de traiter des tâches multiples, avec une sensation de fluidité, et qui gagne en stabilité
J'insiste, car tout comme le HPET, il y aura ceux qui vont réellement "voir" le bénéficie apporté, et d'autres, qui vont prendre cela comme un placebo car ils n'auront rien remarqué de positif
Les joueurs ont la réponse à cette question : Vaut il mieux avoir un PC qui va rester dans la tranche des 60 à 85 FPS constants, qu'un PC qui va passer de 10 FPS à 110 FPS ? avoir des coupures sons, des grésilements, faire du yoyo en permanence (idem avec le processeur qui pourrait tourner à 100%) occasionnant stuttering ou micro stuttering, , tearing etc, stresser les composants, occasionnant de la chauffe (risque de throttling) et j'en oublie.
MAIS attention il peut y avoir un lien avec le HPET (voir le dernier message de ce lien viewtopic.php?p=518296#p518296 ) où on s'aperçoit que l'avantage de la stabilité, voire des performances peut se faire au détriment de la latence
et le soucis étant que c'est lié au hardware, à l'âge du PC, de la carte mère, du processeur, ...et bien entendu de la version de l'OS
Chez moi par ex, j'avais l'IRQ 16 partagée entre la carte vidéo, la carte son et la carte réseau et d'autres (pour la carte réseau le passage en MSI s'est fait tout seul lors d'une mise à jour de pilotes)
Sur une autre copie écran (pas la mienne) en passant par le gestionnaire système on voir le passage en mode MSI
_____________________________________________
PETITE PARTIE TECHNIQUE EXPLICATIVE (Complément)
Tout d'abord un papier de chez INTEL :
https://www.intel.com/content/dam/www/p ... -paper.pdf
Un échange de mail très instructif entre Intel et HP
https://www.kernel.org/doc/Documentatio ... -HOWTO.txt
Chez MICROSOFT
https://docs.microsoft.com/en-us/window ... e-registry
Et pour finir un extrait de "Windows Internals" de Mark Russinovich, David A. Solomon et Alex Ionescu
"Interruptions basées sur la ligne ou sur le message signalé
Les interruptions partagées sont souvent la cause d'une latence élevée des interruptions et peuvent également causer des problèmes de stabilité. Ils sont généralement indésirables et constituent un effet secondaire du nombre limité de lignes d'interruption physiques sur un ordinateur. Par exemple, dans l'exemple précédent du lecteur de carte multimédia 7-en-1, une solution bien meilleure consiste à attribuer à chaque périphérique sa propre interruption et à un pilote de gérer les différentes interruptions en sachant de quel périphérique ils proviennent. Cependant, la consommation de quatre lignes IRQ pour un seul périphérique entraîne rapidement l'épuisement de la ligne IRQ. De plus, les périphériques PCI étant connectés à une seule ligne IRQ, le lecteur de carte mémoire ne peut pas utiliser plus d'une IRQ.
La génération d'interruptions via une ligne IRQ pose également d'autres problèmes, à savoir qu'une gestion incorrecte du signal IRQ peut provoquer des tempêtes d'interruption ou d'autres types d'impasses sur la machine, car le signal est piloté «haut» ou «bas» jusqu'à ce que l'ISR le reconnaisse. (En outre, le contrôleur d'interruption doit généralement recevoir également un signal EOI.) Si l'un de ces problèmes ne se produit pas à cause d'un bogue, le système peut se retrouver dans un état d'interruption pour toujours, des interruptions supplémentaires pourraient être masquées, ou les deux. Enfin, les interruptions basées sur la ligne offrent une faible évolutivité dans les environnements multiprocesseurs. Dans de nombreux cas, le matériel détermine en fin de compte quel processeur sera interrompu en dehors du jeu possible défini par le gestionnaire Plug-and-Play sélectionné pour cette interruption, et les pilotes de périphérique sont limités
Une solution à tous ces problèmes est un nouveau mécanisme d'interruption introduit dans la norme PCI 2.2, appelé interruptions à signalisation signalée (MSI). Bien que cela reste un composant optionnel du standard que l’on trouve rarement sur les ordinateurs clients, un nombre croissant de serveurs et de stations de travail implémentent la prise en charge de MSI, intégralement prise en charge par les versions les plus récentes de Windows. Dans le modèle MSI, un périphérique envoie un message à son pilote en écrivant sur une adresse mémoire spécifique. Cette action provoque une interruption et Windows appelle ensuite l'ISR avec le contenu du message (valeur) et l'adresse à laquelle le message a été remis. Un périphérique peut également transmettre plusieurs messages (jusqu'à 32) à l'adresse de mémoire, en délivrant différentes charges utiles en fonction de l'événement.
Etant donné que la communication est basée sur une valeur de mémoire et que le contenu est livré avec l'interruption, le besoin de lignes IRQ est supprimé (la limite système totale de MSI est égale au nombre de vecteurs d'interruption, et non au nombre de lignes IRQ), de même que besoin d’un ISR de pilote pour interroger le périphérique sur des données relatives à l’interruption, ce qui diminue le temps de latence. En raison du grand nombre d'interruptions de périphérique disponibles via ce modèle, cela annule effectivement tout avantage de partage des interruptions, diminuant encore le temps de latence en fournissant directement les données d'interruption à l'ISR concerné
Enfin, MSI-X, une extension du modèle MSI introduite dans PCI 3.0, ajoute la prise en charge des messages 32 bits (au lieu de 16 bits), d’un maximum de 2 048 messages différents (au lieu de 32), et plus encore. plus important encore, la possibilité d’utiliser une adresse différente (qui peut être déterminée de manière dynamique) pour chacune des charges utiles MSI. L’utilisation d’une adresse différente permet d’écrire la charge utile MSI dans une plage d’adresses physique différente appartenant à un processeur différent, ou à un ensemble différent de processeurs cibles, permettant ainsi une remise d’interruptions tenant compte de l’accès non uniforme à la mémoire (NUMA) en envoyant l’interruption au destinataire. processeur qui a initié la demande de périphérique associé. Cela améliore la latence et l'évolutivité en surveillant à la fois la charge et le nœud NUMA le plus proche pendant la fin de l'interruption.