Architecture informatique: les claviers USB sont-ils moins réactifs en raison de la plage IRQ étroite?

Voici une déclaration à laquelle je viens de penser. Quelqu'un peut-il me dire si, et pourquoi, c'est vrai?

Déclaration: Étant donné que les claviers USB reposent sur un pilote générique USB et une architecture qui n'a accès qu'à des niveaux d'IRQ inférieurs, il ne peut pas donner au clavier un accès à une IRQ aussi prioritaire qu'un autre (disons PS2).

Est-ce que cela (si c'est vrai) signifie que les claviers USB auraient une priorité inférieure (en termes de disponibilité plus que de vitesse) que les claviers branchés sur un autre type de port (comme la PS2)?

Prenons par exemple un clavier USB mappé à une IRQ de priorité moyenne, sur un système défectueux qui est bloqué sur une autre routine d'interruption de priorité moyenne. En raison de sa priorité relativement égale, les événements de clavier seraient ignorés et vous ne pourrez pas envoyer Ctrl-Alt-del ou toute autre frappe d'urgence. Si le clavier avait une priorité plus élevée, le système pourrait entrer dans la routine d'interruption de frappe.

Ou le contrôleur USB a-t-il suffisamment de plage IRQ (que ce soit en priorité ou non en continu) pour donner à votre clavier la priorité dont il a besoin (essentiellement juste en dessous de la panne de courant)?

Et que dire des claviers virtuels, mappés via une connexion réseau sur une session de bureau à distance?

EDIT: Ma question n'est pas beaucoup sur la vitesse (voir les commentaires): la question principale est: un clavier PS2 a-t-il plus de chances de parler à un CPU coincé quelque part sur une priorité d'interruption supérieure à USB et inférieure à clavier?

Il ne s'agit pas de la plage IRQ, il s'agit de trois facteurs principaux:

1. Quantité de foule de bus
2. Quantité de données
3. Longueur du chemin de données

Dans le passé, les claviers et les souris disposaient d'un IRQ dédié (IRQ1 pour les claviers, IRQ12 pour les souris PS / 2).

Cela signifiait que lorsqu'une touche était enfoncée, elle avait une ligne presque directe vers le CPU (via le PIC; mais toujours, un seul saut). Cela a permis aux événements de clavier d'être traités très rapidement dans le matériel, d'autant plus qu'il avait IRQ1. (Bien sûr, tout cela concerne l'utilisation normale du clavier et ignore la ligne de réinitialisation qui va du contrôleur de clavier directement au CPU.)

Les périphériques USB, d'autre part, partagent tous le même bus et l'IRQ du contrôleur USB (qui est généralement l'un des pilotes IRQ partagés avec d'autres périphériques tels que les cartes réseau, les cartes vidéo et autres). En tant que tel, avec un clavier USB, les événements vont du contrôleur de clavier, via le bus USB, au contrôleur hôte USB, de là, au PIC secondaire, puis au PIC maître, puis aux pilotes du système d'exploitation ou du BIOS. , puis sur le CPU. De plus, des données de vérification des erreurs sont ajoutées aux données transférées via USB.

En d'autres termes, il se passe tout simplement plus avec un clavier USB qu'avec un clavier AT ou PS / 2. Le chemin de données est plus long et il y a plus de données, et il peut même être nécessaire de passer par un logiciel . Même si la bande passante USB est suffisamment grande, le fait d'avoir d'autres appareils sur le même port provoque des collisions et des retards (vous pouvez ajouter un concentrateur, mais tous les ports dessus sont toujours le même port sur le contrôleur). Il y a donc beaucoup plus d'attente.

De plus, avoir son propre (IRQ signifiait qu'un clavier plus ancien pouvait interrompre le traitement du CPU quand il le fallait. Avec USB, le clavier n'a pas un tel mécanisme et ne peut envoyer que des données et attendre / espérer que le contrôleur USB interrompt le CPU à un moment donné.

Les claviers virtuels sont encore pires car ils passent définitivement par un logiciel qui bien sûr ne peut pas rivaliser avec une ligne matérielle.

Voici une visualisation simple de la différence entre un clavier AT ou PS / 2 et un clavier USB:

Réponse courte

Les deux claviers fonctionneraient de manière absolument égale pour le code de niveau utilisateur. Il peut y avoir de petites différences ( nano- à micro- secondes sur un PC moderne) si vous écrivez des pilotes de périphérique. Si le système se bloque, les deux claviers ne résoudraient pas le problème. Optez pour un redémarrage dur.

Réponse longue TL; DR;

Qu'est-ce qu'une interruption?

Lorsque le matériel (ou un élément essentiel du logiciel interne du système d'exploitation, comme le noyau) nécessite un service de processeur, il déclenche un message ou une interruption , qui demande au processeur de reporter ce qu'il fait et de gérer cette demande.

Comment ça fonctionne?

Lorsque le matériel génère une interruption (par exemple, une pression sur une touche), cette demande va dans un contrôleur d'interruption. Le contrôleur interrompt alors immédiatement le CPU sur une seule ligne de son code machine (le CPU exécute toujours cette dernière ligne). Une fois que le processeur est prêt à traiter cette demande, il demande à un contrôleur d' interruption une demande d'interruption (IRQ) et une routine de traitement. Le contrôleur d'interruption a une structure de données interne - Interrupt Dispatch Table qui contient un pointeur vers une routine qui est censée être exécutée par le CPU pour une IRQ particulière.

Toutes les différentes interruptions correspondent à un niveau de demande d'interruption limité (IRQL) bien défini . Par exemple, sur les systèmes x86, il y a 32 IRQL, et sur x64 et IA64, il y en a en fait moins - 16 IRQL. De toute évidence, il existe plus de périphériques matériels et de services logiciels que les IRQL, ce qui signifie que tous les objets système partageront les IRQL.

Table IRQLs pour x64

    IRQL | La description
--------------------------------------------
    15 | Haut profil
    14 | Interruption / alimentation interprocesseur
    13 | L'horloge
    12 | Sync
    11 | Périphérique N
    .. | ...
     3 | Appareil 1
     2 | Envoi / DPC
     1 | APC
     0 | Passif / faible

Un IRQL supérieur (avec un plus grand nombre) a une priorité plus élevée. Tous les composants d'un système essaient de maintenir l'IRQL actuel d'un processeur au niveau le plus bas possible - 0. Si une interruption de niveau supérieur se produit, le niveau IRQL actuel d'un processeur est augmenté et les interruptions de niveau inférieur ne seront traitées que toutes les interruptions de niveau supérieur sont résolues. L'IRQ peut être traité par lots si le planificateur d'IRQ est capable de mettre en file d'attente plusieurs IRQ du même niveau pour l'exécution du processeur.

Dans quel but?

Tout cela a été vraiment bien conçu pour séparer l'utilisateur final de la complexité du matériel et créer une architecture universelle qui peut fonctionner avec de nombreux types de matériel / logiciel.

1. Le code au niveau de l'utilisateur (c'est-à-dire pas au niveau du noyau) n'est exécuté que lorsque le processeur est à l'IRQL passif / bas (0). Le fait est que vous ne pouvez gérer un événement appuyé sur une touche dans votre application qu'une fois tous les IRQL traités. Par conséquent, pour un clavier, peu importe quel IRQL est affecté à l'interruption matérielle.

2. IRQL ne sont que des abstractions du système d'exploitation et ne sont pas figés . L'IRQ et l'IRQL correspondants sont stockés dans le registre Windows (par exemple), et tout utilisateur enthousiaste peut les modifier manuellement.

Conclusions

Citations de la question

Parce que les claviers USB reposent sur un pilote générique USB et une architecture qui n'a accès qu'à quelques canaux IRQ, il ne peut pas donner au clavier un accès à une IRQ aussi prioritaire qu'un autre (disons PS2).

L'auteur a peut-être voulu dire un IRQL inférieur au lieu des canaux IRQ moins nombreux . Quoi qu'il en soit, cela n'a pas vraiment d'importance car il n'est pas visible pour l'utilisateur sur n'importe quel PC moderne. Les différences possibles sont de l'ordre de la nano à la micro- seconde et elles ne se produisent qu'au niveau du noyau. Dans les deux cas, le code de niveau utilisateur est bloqué par le noyau du système d'exploitation.

Est-ce que cela (si c'est vrai) signifie que les claviers USB seraient moins réactifs que les claviers branchés sur un autre type de port?

Ce n'est pas vrai à cause de la façon dont le système d'exploitation a été conçu. Si le système d'exploitation est occupé par quelque chose et est "lent", les deux claviers se comporteraient de manière identique.

Prenons par exemple un clavier USB mappé à une IRQ de priorité moyenne, sur un système défectueux qui est bloqué sur une autre routine d'interruption de priorité moyenne

Dans ce cas, le système sera BSOD, les routines de traitement IRQ doivent être conçues jusqu'à un certain standard (telles qu'elles doivent être rapides, synchrones, non bloquantes, etc.). Tout écart par rapport à cela et le noyau BSOD.

En raison de sa priorité relativement égale, les événements de clavier seraient ignorés et vous ne pourrez pas envoyer Ctrl-Alt-del ou toute autre frappe d'urgence.

Si le système se bloque, il y a beaucoup de choses qui peuvent mal tourner, mais très probablement, la frappe IRQL sera gérée au niveau du pilote. Le problème est qu'il ne sera pas remis à l'application qui s'est abonnée à une telle notification, car le système d'exploitation est occupé à faire autre chose.