Architettura del computer: le tastiere USB sono meno reattive a causa della gamma IRQ ridotta?

Ecco una dichiarazione a cui ho appena pensato. Qualcuno può dirmi se, e perché, è vero?

Dichiarazione: poiché le tastiere USB si basano su un driver e un'architettura generici USB che hanno accesso solo a livelli IRQ più bassi, non possono fornire alla tastiera l'accesso a un IRQ con la massima priorità rispetto a un altro controller (diciamo PS2).

Questo (se è vero) significa che le tastiere USB avrebbero una priorità inferiore (in termini di disponibilità più della velocità) rispetto alle tastiere collegate a un altro tipo di porta (come PS2)?

Prendiamo ad esempio una tastiera USB mappata su un IRQ a media priorità, su un sistema difettoso bloccato su un'altra routine di interruzione a media priorità. A causa della sua priorità relativamente uguale, gli eventi della tastiera verrebbero ignorati e non sarà possibile inviare Ctrl-Alt-del o qualsiasi altro tasto di emergenza. Se la tastiera aveva una priorità più alta, il sistema poteva accedere alla routine di interruzione della sequenza di tasti.

Oppure il controller USB ha una gamma IRQ sufficiente (sia che si tratti di priorità in modo continuo o meno) per dare alla tastiera la priorità di cui ha bisogno (in pratica appena sotto l'interruzione di corrente)?

E che dire delle tastiere virtuali, mappate tramite una connessione di rete su una sessione di desktop remoto?

EDIT: La mia domanda non riguarda molto la velocità (vedi commenti): la domanda principale è: una tastiera PS2 ha più possibilità di parlare con una CPU bloccata da qualche parte con una priorità di interrupt superiore a USB e inferiore a quella della tastiera?

Non riguarda la gamma IRQ, riguarda tre fattori principali:

1. Quantità di affollamento di autobus
2. Quantità di dati
3. Lunghezza del percorso dati

In passato, tastiere e mouse avrebbero un IRQ dedicato (IRQ1 per tastiere, IRQ12 per mouse PS / 2).

Ciò significava che quando un tasto veniva premuto, aveva una linea quasi diretta alla CPU (tramite il PIC; ma comunque, solo un salto di distanza). Ciò ha consentito di elaborare gli eventi della tastiera molto velocemente nell'hardware, in particolare poiché aveva IRQ1. (Ovviamente si tratta del normale utilizzo della tastiera e ignora la linea di ripristino che va dal controller della tastiera direttamente alla CPU.)

I dispositivi USB, d'altra parte, condividono tutti lo stesso bus e l'IRQ del controller USB (che di solito è uno di quelli IRQ condivisi con altri dispositivi come schede NIC, schede video e simili). Pertanto, con una tastiera USB, gli eventi passano dal controller della tastiera, attraverso il bus USB al controller host USB, da lì al PIC secondario, quindi al PIC master, quindi ai driver nel sistema operativo o nel BIOS , quindi sulla CPU. Inoltre, vi sono dati di controllo degli errori aggiunti ai dati trasferiti tramite USB.

In altre parole, c'è semplicemente più successo con una tastiera USB che con una tastiera AT o PS / 2. Il percorso dei dati è più lungo e ci sono più dati e potrebbe anche essere necessario passare attraverso il software . Anche se la larghezza di banda USB è sufficientemente grande, avere altri dispositivi sulla stessa porta provoca collisioni e ritardi (è possibile aggiungere un hub, ma tutte le porte su di esso sono sempre la stessa porta sul controller). Quindi c'è molto di più in corso.

Inoltre, avendo il suo (IRQ significava che una tastiera più vecchia poteva interrompere l'elaborazione della CPU ogni volta che era necessario. Con USB, la tastiera non ha tale meccanismo e può solo inviare alcuni dati e attendere / sperare che il controller USB interrompa la CPU ad un certo punto.

Le tastiere virtuali sono anche peggio perché passano sicuramente attraverso software che ovviamente non possono competere con una linea hardware.

Ecco una semplice visualizzazione della differenza tra una tastiera AT o PS / 2 e una tastiera USB:

Risposta breve

Entrambe le tastiere si comportano in modo assolutamente uguale per il codice a livello di utente. Potrebbero esserci delle piccole differenze (da nano a micro secondi su un PC moderno) se si scrivono i driver di dispositivo. Se il sistema si blocca, entrambe le tastiere non risolverebbero il problema. Vai per un riavvio difficile.

Risposta lunga TL; DR;

Che cos'è un interrupt?

Quando l'hardware (o qualche componente critico del software interno del sistema operativo, come il kernel) richiede un servizio di processore, attiva un messaggio o un interrupt , che richiede al processore di posticipare qualunque cosa stia facendo e gestire questa richiesta.

Come funziona?

Quando l'hardware genera un interrupt (ad es. Una pressione di un tasto), questa richiesta entra in un controller di interrupt. Il controller quindi interrompe immediatamente la CPU su una singola riga del suo codice macchina (la CPU esegue ancora quest'ultima riga). Una volta che il processore è pronto a soddisfare questa richiesta, richiede a un controller di interruzione una richiesta di interruzione (IRQ) e una routine di gestione. Il controller di interrupt ha una struttura dati interna: la tabella di invio degli interrupt che contiene un puntatore a una routine che dovrebbe essere eseguita dalla CPU per un particolare IRQ.

Tutti i diversi interrupt corrispondono a un livello di richiesta di interruzione limitato (IRQL) ben definito . Ad esempio sui sistemi x86 ci sono 32 IRQL e su x64 e IA64 ce ne sono effettivamente meno - 16 IRQL. Chiaramente, ci sono più dispositivi hardware e servizi software rispetto agli IRQL, il che significa che tutti gli oggetti di sistema condivideranno gli IRQL.

Tabella IRQL per x64

    IRQL | Descrizione
--------------------------------------------
    15 | Alto profilo
    14 | Interruzione / potenza dell'interprocessore
    13 | Orologio
    12 | Sync
    11 | Dispositivo n
    .. | ...
     3 | Dispositivo 1
     2 | Spedizione / DPC
     1 | APC
     0 | Passive / Basso

I più alti IRQL (con un numero maggiore) hanno una priorità più alta. Tutti i componenti di un sistema tentano di mantenere l'attuale IRQL di un processore al livello più basso possibile - 0. Se si verifica un interrupt di livello superiore, il livello IRQL corrente di un processore viene aumentato e gli interrupt di livello inferiore non verranno gestiti fino a quando tutti gli interrupt con livelli più alti vengono risolti. IRQ può essere gestito in batch se lo scheduler IRQ è in grado di mettere in coda diversi IRQ dello stesso livello per l'esecuzione del processore.

Qual è il punto?

Tutto questo è stato davvero ben progettato per separare l'utente finale dalla complessità dell'hardware e creare un'architettura universale in grado di funzionare con molti tipi di hardware / software.

1. Il codice a livello di utente (cioè non a livello di kernel) viene eseguito solo quando il processore si trova nell'IRQL Passivo / Basso (0). Il punto è che puoi gestire un evento premuto il tasto nella tua applicazione solo dopo aver gestito tutti gli IRQL. Pertanto, per una tastiera non importa quale IRQL sia assegnato all'interrupt hardware.

2. IRQL sono solo astrazioni del sistema operativo e non sono impostate su pietra . I corrispondenti IRQ e IRQL sono memorizzati nel registro di Windows (ad esempio) e qualsiasi utente entusiasta può modificarli manualmente.

conclusioni

Citazioni dalla domanda

Poiché le tastiere USB si basano su un driver e un'architettura USB generici che hanno accesso solo a pochi canali IRQ, non possono fornire alla tastiera l'accesso a un IRQ con priorità elevata come farebbe un altro controller (diciamo PS2).

Forse l'autore voleva dire IRQL più basso invece di un minor numero di canali IRQ . Ad ogni modo, non importa davvero in quanto non è visibile all'utente su nessun PC moderno. Le possibili differenze riguardano il livello da nano a micro secondi e si verificano solo a livello di kernel. In entrambi i casi il codice a livello di utente è bloccato dal kernel del sistema operativo.

Questo (se è vero) significa che le tastiere USB sarebbero meno reattive rispetto alle tastiere collegate a un altro tipo di porta?

Non è vero a causa del modo in cui il sistema operativo progettato. Se il sistema operativo è occupato con qualcosa ed è "lento", entrambe le tastiere si comporterebbero in modo identico.

Prendiamo ad esempio una tastiera USB mappata su un IRQ a media priorità, su un sistema difettoso bloccato su un'altra routine di interruzione a media priorità

In questo caso il sistema sarà BSOD, le routine di gestione IRQ devono essere progettate secondo un certo standard (come devono essere veloci, sincrone, non bloccanti ecc.). Qualsiasi deviazione da questo e dal kernel sarà BSOD.

A causa della sua priorità relativamente uguale, gli eventi della tastiera verrebbero ignorati e non sarà possibile inviare Ctrl-Alt-del o qualsiasi altro tasto di emergenza.

Se il sistema si blocca, ci sono molte cose che possono andare storte, ma molto probabilmente la sequenza di tasti IRQL verrà gestita a livello di driver. Il problema è che non verrà recapitato all'applicazione che ha sottoscritto tale notifica, poiché il sistema operativo è impegnato a fare qualcos'altro.