Clever Geek Handbook

Linux en tiempo real



Se necesita un sistema operativo en tiempo real cuando se imponen requisitos de tiempo al procesador o al flujo de datos. Por lo tanto, a menudo desempeña el papel de una unidad de control en dispositivos especiales. Los experimentos científicos, las aplicaciones de imágenes médicas y los dispositivos de control industrial son sistemas en tiempo real. Los mecanismos de inyección de combustible de motores de automóviles, controladores para equipos domésticos y militares también son sistemas en tiempo real.



Además, los diferentes eventos tienen diferentes requisitos de tiempo. Por ejemplo, el requisito de latencia para un sistema de frenos antibloqueo puede oscilar entre 3 y 5 milisegundos. Es decir, desde el momento en que la rueda detecta por primera vez que patina, el sistema que controla los frenos antibloqueo dispone de 3-5 milisegundos para reaccionar y corregir la situación.



Las capacidades del kernel en tiempo real existen desde hace más de una década en el ecosistema de código abierto. El soporte de Red Hat Enterprise Linux (RHEL) para el kernel en tiempo real ha estado disponible durante la misma cantidad de tiempo. Sin embargo, muchos administradores de sistemas malinterpretan sus conceptos básicos y su comportamiento operativo real. En este artículo, describiré algunas de sus características principales, las diferencias con el kernel estándar y los pasos de instalación.



Programador de CPU en tiempo real



Para diferentes clases de problemas, se pueden designar sistemas blandos en tiempo real y sistemas duros en tiempo real . El primero no garantiza la hora exacta en la que se programará el proceso crítico en tiempo real. Solo garantizan que el proceso se verá favorecido sobre los procesos no críticos. Estos últimos tienen requisitos más estrictos y la tarea se completa dentro del período de tiempo especificado o se considera no completada.



Llamamos retraso de evento al tiempo que transcurre desde el momento en que ocurre el evento hasta el momento en que recibe servicio. Hay dos tipos de retrasos que afectan el rendimiento del sistema operativo en tiempo real.



  • CPU . , . , interrupt service routine (ISR).





    . 1 .
  • , , . , . .





    . 2 .






La característica más importante de un sistema operativo en tiempo real es responder de inmediato a un proceso crítico que requiere acceso a los recursos de la CPU. Como resultado, el programador del sistema operativo en tiempo real debe admitir el algoritmo de interrupción preventiva. Estos algoritmos asignan prioridad a cada proceso en función de su grado de importancia. Si el planificador también admite la preferencia, el proceso actual en la CPU se sustituirá a pedido a favor de un proceso de mayor prioridad.





Figura: 3 Clasificación de planificadores.



Existen varios algoritmos para el planificador en tiempo real.



  • Rate-Monotonic Scheduling — . , . .





    n, ln2 ≈ 0.693147.
  • Earliest-deadline-first (EDF) Scheduling . , , . RMS, EDF , . , , .





    . 4 EDF.



    . 4 T1 T2 , T2. T3 T1, 23.
  • POSIX real-time-scheduling. POSIX.4 . , .



    • SCHED_FIFO — , « — » (FIFO). 32 .
    • SCHED_RR — SCHED_FIFO, ( ) . 32 .
    • SCHED_OTHER — ; - .




Instalación y uso de RHEL Real Time



Primero, debe conectar el repositorio de Red Hat Enterprise Linux Real Time e instalar el grupo de paquetes RT. 



[root@server ~]# subscription-manager repos --enable rhel-8-for-x86_64-rt-rpms
[root@server ~]# yum groupinstall RT


RT incluye estos componentes:



  • kernel-rt : kernel con funcionalidad en tiempo real;
  • rt-setup : instalación del entorno Red Hat Enterprise Linux Real Time;
  • rt-tests : utilidades de prueba de función RT;
  • rt-eval - para evaluar la posibilidad de usar RT en un sistema dado;


Después de instalar RT y reiniciar, asegúrese de que el kernel-rt esté cargado. 



[root@server ~]# uname -a
Linux rt-server.example.com 4.18.0-80.rt9.138.el8.x86_64 …


Echemos un vistazo a algunas de las diferencias entre kernel-rt y el kernel estándar.



  • Con carga alta, se comprueba la prioridad de la tarea (1-99).
  • Las tareas de alta prioridad (99) tienen preferencia al acceder a los recursos de la CPU.
  • No hace cumplir la política de Programación Completamente Justa (CFS) .
  • Utiliza la política SCHED_FIFO o SCHED_RR .




Figura: 5 Comparando kernet_rt con el kernel estándar.





El gráfico muestra una muestra del tiempo de respuesta de un millón de repeticiones para los sistemas que utilizan los kernels RHEL Linux 7 y RHEL Real Time, respectivamente. Los puntos azules en este gráfico representan los tiempos de respuesta (en microsegundos) de los sistemas con el kernel estándar RHEL 7, y los puntos verdes representan RHEL 7 Real Time. Puede verse en el gráfico que la característica de kernel-rt es mucha menos varianza y, en consecuencia, más previsibilidad del tiempo de respuesta del sistema.



Configuración y prueba



Después de instalar RT, es posible que se requieran ajustes y ajustes adicionales para lograr tiempos de respuesta del sistema más consistentes. Dichos requisitos pueden ser presentados por empresas del sector financiero o de telecomunicaciones. La configuración en sí es un proceso iterativo y debe ser paciente al comienzo del proceso. Es poco probable que sea posible modificar un par de variables y comprender que se logra el mejor resultado posible.



La utilidad hwlatdetect del paquete rt-tests mostrará la latencia causada por el hardware y el firmware al sondear la fuente del reloj y buscar espacios oscuros. 



[root@server ~]#  hwlatdetect --duration=60s
hwlatdetect:  test duration 60 seconds
	detector: tracer
	parameters:
		Latency threshold: 10us
		Sample window:     1000000us
		Sample width:      500000us
		Non-sampling period:  500000us
		Output File:       None

Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0
Samples exceeding threshold: 0


En este ejemplo, los parámetros indican el método de retardo y detección. El umbral de latencia predeterminado se estableció en 10 microsegundos (10 μs).



RT también tiene una utilidad llamada rteval para probar el rendimiento del sistema en tiempo real bajo carga. El programa coloca una gran carga en el sistema utilizando el programador SCHED_OTHER y luego mide la respuesta en tiempo real en cada una de las CPU activas. El objetivo es mantener varias tareas en ejecución de forma continua, como la asignación / liberación de memoria, E / S de disco, cálculo, copia de memoria y otras.



Cada hilo de medición toma una marca de tiempo, muere durante un cierto intervalo y luego toma otra marca de tiempo al despertarse. El retardo de la medición es igual a t1 - (t0 + i), donde



  • t1 - tiempo de medición real;
  • t0 - hora teórica de activación de la primera marca de tiempo;
  • i es el intervalo de espera.


El informe de la utilidad rteval se ve así. 



System:
Statistics:
	Samples:           1440463955
	Mean:              4.40624790712us
	Median:            0.0us
	Mode:              4us
	Range:             54us
	Min:               2us
	Max:               56us
	Mean Absolute Dev: 1.0776661507us
	Std.dev:           1.81821060672us

CPU core 0       Priority: 95
Statistics:
	Samples:           36011847
	Mean:              5.46434910711us
	Median:            4us
	Mode:              4us
	Range:             38us
	Min:               2us
	Max:               40us
	Mean Absolute Dev: 2.13785341159us
	Std.dev:           3.50155558554us


Materiales usados











More articles:


All Articles