El sched_setscheduler(2) y sus amigos le permiten usar dos programadores suaves en tiempo real diferentes, SCHED_FIFO SCHED_RR. Los procesos que se ejecutan bajo estos programadores tienen una prioridad más alta que los procesos regulares. Entonces, siempre que solo tenga algunos de estos procesos y controle las prioridades entre ellos, puede obtener respuestas bastante decentes en tiempo real.
Como se solicitó en un comentario, aquí está la diferencia entre SCHED_FIFO y SCHED_RR:
Con los programadores en "tiempo real", hay hasta 100 prioridades diferentes (POSIX solo requiere 32 niveles distintos, por lo que se deben usar sched_get_priority_min(2) y sched_get_priority_max(2) para obtener el número real. Ambos programadores funcionan adelantando procesos y subprocesos con menor prioridad, la diferencia está en cómo manejan las tareas con la misma prioridad.
SCHED_FIFO, es un programador de primeras entradas, primeras salidas (de ahí el nombre). Esto significa que la tarea que llega primero a la cola de ejecución, puede ejecutarse hasta que finalice, cede voluntariamente su espacio en la cola de ejecución o es reemplazada por una tarea de mayor prioridad.
SCHED_RR, es un planificador de turnos. Esto significa que las tareas con la misma prioridad solo pueden ejecutarse durante un tiempo determinado. Si la tarea todavía se está ejecutando cuando se agota este cuanto de tiempo, la tarea se reemplaza y la siguiente tarea en la cola de ejecución (con la misma prioridad) puede ejecutarse hasta su cuanto de tiempo. Al igual que con SCHED_FIFO, las tareas de mayor prioridad reemplazan a las de menor prioridad; sin embargo, cuando una tarea que fue reemplazada por una tarea de mayor prioridad puede ejecutarse nuevamente, solo puede ejecutarse durante el tiempo restante en su cantidad. Consulte la sección Noes en sched_rr_get_interval(2) para saber cómo establecer la cantidad de tiempo para una tarea.
MRG
Será difícil garantizar submilisegundos en un kernel que no sea RT. Sé que se ha realizado un gran trabajo en los últimos años (p. ej., el gran bloqueo del núcleo se ha ido), pero aún no es suficiente para garantizarlo.
Podrías echar un vistazo a Scientific Linux de esos amigables molestos atómicos en CERN y Fermilab. Eso puede tener MRG instalado (vea mi enlace), lo que le brinda una configuración preempaquetada del parche PREEMPT_RT.
O si tiene el dinero, puede obtener Redhat MRG. Esa es una distribución de Linux totalmente compatible con el parche PREEMPT-RT incorporado, por lo que eliminaría el parche propenso a problemas del kernel.
La cuestión es que Redhat cobra mucho mucho por ello ($3000 AL AÑO POR INSTALACIÓN). Creo que se han dado cuenta de que uno de los mayores clientes son los inversores de comercio de alta velocidad que todavía tienen montones y montones de dólares y, por lo tanto, no se darán cuenta de que se van a la basura $3000/caja/año.
Cómo me fue bien con MRG
He trabajado bastante con MRG (usando los dos anteriores), y es bastante bueno. Reemplaza las rutinas de servicio de interrupción en el kernel estándar con subprocesos para atender la interrupción. ¡Eso significa que puede ejecutar su software con prioridades más altas que los subprocesos IRQ! Ese es el tipo de cosas que tienes que hacer si quieres acercarte a garantizar latencia de submilisegundos en su aplicación.
Parece haber una deriva gradual de las cosas de MRG hacia el núcleo de la línea principal, lo cual es algo bueno en mi opinión. Tal vez algún día se convierta en algo principal.
Otras trampas
La gestión térmica de la CPU moderna puede ser un verdadero dolor de cabeza. He tenido sistemas que se bloquean durante 0,3 segundos mientras se reparaba una Interrupción de administración del sistema (por el BIOS sangrante, no por el sistema operativo), solo porque la CPU se calentó un poco. Mira esto. Por lo tanto, debe tener cuidado con lo que hace su hardware subyacente. Por lo general, debe comenzar a preocuparse por deshacerse del enfriamiento administrado de las PC modernas y volver a un gran ventilador que gira rápidamente todo el tiempo.
Puede llegar bastante lejos con Linux eliminando la 'perturbación' de otros procesos al proceso en tiempo real. Jugué con lo mismo en Windows, que es un horror mucho mayor para hacerlo bien, pero muestra la dirección. Así que una especie de lista de control:
- Lo más importante (extraño pero cierto):el hardware. No elija una computadora portátil, esta se optimizará para hacer cosas extrañas durante las interrupciones de SMM. No puedes hacer nada.
- Los controladores:Linux (y Windows) tiene controladores buenos y malos. Relacionado con el hardware. Y solo hay una forma de averiguarlo:evaluación comparativa.
Aislar del resto del sistema, deshabilitar todos los usos compartidos:
- Aislar una CPU (
man cpuset). Cree dos conjuntos de CPU, uno para procesos normales y otro para su proceso en tiempo real. - Reduzca al mínimo la parte en tiempo real de su código. Comuníquese con gran búfer con otras partes del sistema. Reduzca IO al mínimo (ya que IO tiene malas garantías).
- Haga que el proceso tenga la prioridad más alta (suave) en tiempo real.
- Deshabilitar HyperThreading (no desea compartir)
- preasigna la memoria que necesita y mlock() la memoria.
- Aísla los dispositivos que usas. Comience asignando una IRQ dedicada al dispositivo (mueva los otros dispositivos a otra IRQ o elimine otros dispositivos/controladores).
- Aísle el IO que usa.
Reducir la actividad del resto del sistema:
- solo inicie los procesos que realmente necesita.
- elimine el hardware que no necesita, como discos y otro hardware.
- deshabilitar el intercambio.
- no utilice módulos del kernel de Linux ni los cargue por adelantado. El inicio de los módulos es impredecible.
- preferiblemente elimine al usuario también :)
Hazlo estable y reproducible:
- desactive todos los ahorros de energía. Quiere el mismo rendimiento todo el tiempo.
- Revise todas las configuraciones del BIOS y elimine todos los 'eventos' y 'compartir' de ellos. Así que no hay pasos de velocidad sofisticados, gestión térmica, etc. Elija baja latencia, no elija cosas con "ráfaga" en el nombre, ya que generalmente cambia el rendimiento por un peor rendimiento.
- Revise la configuración del controlador de Linux y reduzca las latencias (si corresponde).
- usar un kernel reciente que trate de parecer un kernel en tiempo real cada día un poco más.
Y luego haga una evaluación comparativa, usando pruebas de estrés y dejando la máquina encendida durante días mientras registra un máximo. latencias.
Entonces:buena suerte :)