Clever Geek Handbook

Linux en temps réel



Un système d'exploitation en temps réel est nécessaire lorsque des exigences de temps sont imposées au processeur ou au flux de données. Ainsi, il joue souvent le rôle d'unité de contrôle dans des dispositifs spéciaux. Les expériences scientifiques, les applications d'imagerie médicale, les dispositifs de contrôle industriels sont des systèmes en temps réel. Les mécanismes d'injection de carburant des moteurs automobiles, les contrôleurs des équipements ménagers et militaires sont également des systèmes en temps réel.



De plus, différents événements ont des exigences de temps différentes. Par exemple, l'exigence de latence pour un système de freinage antiblocage peut aller de 3 à 5 millisecondes. Autrement dit, à partir du moment où la roue détecte pour la première fois qu'elle patine, le système qui contrôle les freins antiblocage dispose de 3 à 5 millisecondes pour réagir et corriger la situation.



Les capacités du noyau en temps réel existent depuis plus d'une décennie dans l'écosystème open source. La prise en charge de Red Hat Enterprise Linux (RHEL) pour le noyau en temps réel est disponible depuis le même laps de temps. Cependant, de nombreux administrateurs système interprètent mal ses concepts de base et son comportement d'exploitation réel. Dans cet article, je décrirai certaines de ses principales fonctionnalités, les différences par rapport au noyau standard et les étapes d'installation.



Planificateur CPU en temps réel



Pour différentes classes de problèmes, on peut désigner des systèmes temps réel souples et des systèmes temps réel durs . Le premier ne garantit pas l'heure exacte à laquelle le processus critique sera planifié en temps réel. Ils garantissent seulement que le processus sera favorisé par rapport aux processus non critiques. Ces derniers ont des exigences plus strictes et la tâche est soit achevée dans le délai spécifié, soit considérée comme non achevée.



Nous appelons le délai d'événement le temps qui s'écoule entre le moment où l'événement se produit et le moment où il est traité. Il existe deux types de retards qui affectent les performances du système d'exploitation en temps réel.



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





    . 1 .
  • , , . , . .





    . 2 .






La caractéristique la plus importante d'un système d'exploitation en temps réel est de répondre immédiatement à un processus critique qui nécessite un accès aux ressources du processeur. En conséquence, le planificateur du système d'exploitation en temps réel doit prendre en charge l'algorithme d'interruption préventive. Ces algorithmes attribuent la priorité à chaque processus en fonction de son degré d'importance. Si l'ordonnanceur prend également en charge la préemption, le processus en cours sur le processeur sera préempté à la demande en faveur d'un processus de priorité plus élevée.





Figure: 3 Classification des planificateurs.



Il existe plusieurs algorithmes pour le planificateur en temps réel.



  • 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 — ; - .




Installation et utilisation de RHEL en temps réel



Tout d'abord, vous devez connecter le référentiel Red Hat Enterprise Linux Real Time et installer le groupe de packages RT. 



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


RT comprend ces composants:



  • kernel-rt - noyau avec des fonctionnalités en temps réel;
  • rt-setup - installation de l'environnement Red Hat Enterprise Linux Real Time;
  • rt-tests - utilitaires de test de fonction RT;
  • rt-eval - pour évaluer la possibilité d'utiliser RT sur un système donné;


Après avoir installé RT et redémarré, assurez-vous que le kernel-rt est chargé. 



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


Jetons un coup d'œil à certaines des différences entre kernel-rt et le noyau standard.



  • En cas de charge élevée, la priorité de la tâche est vérifiée (1-99).
  • Les tâches de haute priorité (99) ont la préférence lors de l'accès aux ressources du processeur.
  • N'applique pas la politique de planification complètement équitable (CFS) .
  • Utilise la stratégie SCHED_FIFO ou SCHED_RR .




Figure: 5 Comparaison de kernet_rt avec le noyau standard.





Le graphique montre un échantillon du million de temps de réponse de répétition pour les systèmes utilisant respectivement les noyaux RHEL Linux 7 et RHEL Real Time. Les points bleus dans ce graphique représentent les temps de réponse (en microsecondes) des systèmes avec le noyau RHEL 7 standard, et les points verts représentent le temps réel RHEL 7. Le graphique montre que la caractéristique de kernel-rt est une variance beaucoup plus faible et, par conséquent, une plus grande prévisibilité du temps de réponse du système.



Mise en place et test



Une fois RT installé, des réglages et des ajustements supplémentaires peuvent être nécessaires pour obtenir les temps de réponse du système les plus cohérents. Ces exigences peuvent être présentées par des entreprises du secteur financier ou des télécommunications. La configuration elle-même est un processus itératif et vous devez être patient au début du processus. Il est peu probable qu'il soit possible d'ajuster quelques variables et de comprendre que le meilleur résultat possible a été obtenu.



L'utilitaire hwlatdetect du package rt-tests montrera la latence causée par le matériel et le micrologiciel en interrogeant la source d'horloge et en recherchant des lacunes obscures. 



[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


Dans cet exemple, les paramètres indiquent le délai et la méthode de détection. Le seuil de latence par défaut a été défini sur 10 microsecondes (10 μs).



RT dispose également d'un utilitaire appelé rteval pour tester les performances du système en temps réel sous charge. Le programme place une lourde charge sur le système à l'aide du planificateur SCHED_OTHER, puis mesure la réponse en temps réel sur chacun des processeurs actifs. L'objectif est de maintenir diverses tâches en cours d'exécution en continu, telles que l'allocation / la libération de mémoire, les E / S disque, le calcul, la copie de mémoire, etc.



Chaque thread de mesure prend un horodatage, est inactif pendant un certain intervalle, puis prend un autre horodatage au réveil. Le retard de mesure est égal à t1 - (t0 + i), où



  • t1 - temps de mesure réel;
  • t0 - heure de réveil théorique du premier horodatage;
  • i est l'intervalle d'attente.


Le rapport de l'utilitaire rteval ressemble à ceci. 



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


Matériaux utilisés











More articles:


All Articles