Aquí hay una declaración que acabo de pensar. ¿Alguien puede decirme si es cierto y por qué?
Declaración: Debido a que los teclados USB se basan en un controlador genérico USB y una arquitectura que solo tiene acceso a niveles más bajos de IRQ, no puede otorgarle al teclado un IRQ con la prioridad más alta que otro controlador (por ejemplo, PS2).
¿Significa esto (si es cierto) que los teclados USB tendrían menor prioridad (en términos de disponibilidad más que velocidad) que los teclados conectados a otro tipo de puerto (como PS2)?
Tomemos, por ejemplo, un teclado USB asignado a una IRQ de prioridad media, en un sistema defectuoso que está atascado en otra rutina de interrupción de prioridad media. Debido a su prioridad relativamente igual, se ignorarían los eventos del teclado y no podrá enviar Ctrl-Alt-del ni ninguna otra tecla de emergencia. Si el teclado tuviera una prioridad más alta, el sistema podría ingresar a la rutina de interrupción de pulsación de tecla.
¿O el controlador USB tiene suficiente rango de IRQ (sea continuo o no) para darle a su teclado la prioridad que necesita (básicamente justo por debajo del fallo de alimentación)?
¿Y qué pasa con los teclados virtuales, asignados a través de una conexión de red en una sesión de escritorio remoto?
EDITAR: Mi pregunta no es mucho sobre la velocidad (ver comentarios): la pregunta principal es: ¿un teclado PS2 tiene más posibilidades de hablar con una CPU que está atascada en algún lugar con una prioridad de interrupción mayor que USB y menor que el teclado?
Respuestas:
No se trata del rango IRQ, se trata de tres factores principales:
En el pasado, los teclados y ratones tendrían una IRQ dedicada (IRQ1 para teclados, IRQ12 para ratones PS / 2).
Esto significaba que cuando se presionaba una tecla, tenía una línea casi directa a la CPU (a través del PIC; pero aún así, solo un salto). Esto permitió que los eventos del teclado se procesaran muy rápido en el hardware, particularmente porque tenía IRQ1. (Por supuesto, esto se trata del uso normal del teclado e ignora la línea de reinicio que va desde el controlador del teclado directamente a la CPU).
Por otro lado, todos los dispositivos USB comparten el mismo bus y la IRQ del controlador USB (que generalmente es una de las direcciones de IRQ que se comparte con otros dispositivos como NIC, tarjetas de video y demás). Como tal, con un teclado USB, los eventos van desde el controlador del teclado, a través del bus USB al controlador host USB, desde allí, al PIC secundario, luego al PIC maestro, luego a los controladores en el sistema operativo o el BIOS , luego a la CPU. Además, hay datos de comprobación de errores agregados a los datos transferidos a través de USB.
En otras palabras, simplemente sucede más con un teclado USB que con un teclado AT o PS / 2. La ruta de datos es más larga y hay más datos, e incluso puede que tenga que pasar por el software . Aunque el ancho de banda USB es lo suficientemente grande, tener otros dispositivos en el mismo puerto provoca colisiones y retrasos (puede agregar un concentrador, pero todos los puertos en él siguen siendo el mismo puerto en el controlador). Entonces hay mucho más esperando.
Además, tener su propio (IRQ significaba que un teclado antiguo podría interrumpir el procesamiento de la CPU cuando fuera necesario. Con USB, el teclado no tiene dicho mecanismo y solo puede enviar algunos datos y esperar / esperar que el controlador USB interrumpa la CPU en algún momento.
Los teclados virtuales son aún peores porque definitivamente pasan por un software que, por supuesto, no puede competir con una línea de hardware.
Aquí hay una visualización simple de la diferencia entre un teclado AT o PS / 2 y un teclado USB:
fuente
Ctrl+Alt+Del
don ' No funcionan a través de una línea de hardware, sino que se procesan mediante software.Respuesta corta
Ambos teclados funcionarían absolutamente igual para el código de nivel de usuario. Puede haber pequeñas diferencias ( nano- a microsegundos en una PC moderna) si escribe controladores de dispositivo. Si el sistema se bloquea, ambos teclados no resolverían el problema. Ir para reiniciar duro.
Respuesta larga TL; DR;
¿Qué es una interrupción?
Cuando el hardware (o alguna pieza crítica del software interno del sistema operativo, como el kernel) requiere un servicio de procesador, dispara un mensaje o una interrupción , que solicita al procesador que posponga lo que esté haciendo y maneje esta solicitud.
¿Cómo funciona?
Cuando el hardware genera una interrupción (por ejemplo, presionar una tecla), esta solicitud pasa a un controlador de interrupción. El controlador interrumpe inmediatamente la CPU en una sola línea de su código de máquina (la CPU aún ejecuta esta última línea). Una vez que el procesador está listo para atender esta solicitud, le pide a un controlador de interrupción una solicitud de interrupción (IRQ) y una rutina de manejo. El controlador de interrupción tiene una estructura de datos interna: tabla de envío de interrupción que contiene un puntero a una rutina que la CPU debe ejecutar para una IRQ particular.
Todas las interrupciones diferentes corresponden a un nivel de solicitud de interrupción limitada (IRQL) bien definido . Por ejemplo, en los sistemas x86 hay 32 IRQL, y en x64 e IA64 en realidad hay menos: 16 IRQL. Claramente, que hay más dispositivos de hardware y servicios de software que los IRQL, lo que significa que todos los objetos del sistema compartirán los IRQL.
Tabla de IRQL para x64
Mayor IRQL (con mayor número) tiene mayor prioridad. Todos los componentes de un sistema intentan mantener el IRQL actual de un procesador en el nivel más bajo posible - 0. Si se produce una interrupción de nivel superior, entonces se eleva el nivel de IRQL actual de un procesador y las interrupciones con nivel inferior no se manejarán hasta Todas las interrupciones con niveles más altos se resuelven. IRQ se puede manejar por lotes si el planificador IRQ puede poner en cola varios IRQ del mismo nivel para la ejecución del procesador.
¿Cual es el punto?
Todo esto ha sido muy bien diseñado para separar al usuario final de las complejidades del hardware y crear una arquitectura universal que pueda funcionar con muchos tipos de hardware / software.
El código de nivel de usuario (es decir, no el nivel de kernel) solo se ejecuta cuando el procesador está en el IRQL pasivo / bajo (0). El punto es que solo puede manejar un evento de pulsación de tecla en su aplicación después de que se hayan manejado todos los IRQL. Por lo tanto, para un teclado no importa qué IRQL esté asignado a la interrupción de hardware.
IRQL son solo abstracciones del sistema operativo y no están establecidas en piedra . Los IRQ e IRQL correspondientes se almacenan en el registro de Windows (por ejemplo), y cualquier usuario entusiasta puede cambiarlos manualmente.
Conclusiones
Citas de la pregunta
Quizás el autor quiso decir IRQL más bajo en lugar de menos canales IRQ . De todos modos, realmente no importa, ya que no es visible para el usuario en ninguna PC moderna. Las posibles diferencias son del nivel de nanosegundos a microsegundos y solo ocurren a nivel del núcleo. En ambos casos, el núcleo del sistema operativo bloquea el código de nivel de usuario.
No es cierto debido a la forma en que se diseñó el sistema operativo. Si el sistema operativo está ocupado con algo y es "lento", ambos teclados se comportarían de manera idéntica.
En este caso, el sistema BSOD, las rutinas de manejo de IRQ deben diseñarse según un cierto estándar (como deben ser rápidas, sincrónicas, sin bloqueo, etc.). Cualquier desviación de esto y el núcleo BSOD.
Si el sistema se bloquea, hay muchas cosas que pueden salir mal, pero lo más probable es que el IRQL de la pulsación de tecla se maneje a nivel del controlador. El problema es que no se entregará a la aplicación que se suscribió a dicha notificación, ya que el sistema operativo está ocupado haciendo otra cosa.
fuente