Temps Réel

Un article de Wiki de la communauté Mandriva.

Sommaire 1 Introduction 2 Références 3 Temps-réel dur pour Mandriva 3.1 Le noyau 3.1.1 Installation 3.1.2 Les tests 3.1.2.1 RT-Tests 3.1.2.2 PowerTop 3.1.2.3 LatencyTop 3.1.2.4 LMbench 3.2 Le système 3.2.1 PAM 3.2.2 ACPI 3.2.3 USB 4 Conclusion

[modifier] Introduction

Le temps partagé était un fonctionnement simple : chaque application et service est vue comme égalitaire aux autres.

"Temps Réel", quant à lui, est un faux ami : le terme exact serait peut être plus "Temps Déterminé". Un système permettant de soumettre des taches à des notions de temps précis et choisis. Le temps nécessaire pour obtenir les résultats d' opérations effectuées par les taches choisies, est déterminé d' avance et donc prédictible. Deux types de temps réel sont distinguables : le type "dur" le temps déterminé non respecté entraine une faute sur pour ce résultat, dans son ensemble. Le type "mou" où un dépassement du temps déterminé est autorisé. Ce dernier est le plus adapté pour une utilisation quotidienne de l' ordinateur d' un petit studio : il n' est pas important que de temps en temps, un décrochage de 10 ou 15 millisecondes se fasse sur un calcul pour une seule période de son, par exemple. (néanmoins on peux tout à fait utiliser un kernel-rt dans le même cadre)

La notion de ressources partagées : un accès en écriture sur le disque dur entraîne un laps de temps avant qu'un autre accès en écriture soit possible : la disponibilité de ce matériel n'est donc que peu prévisible.

L'ordonnanceur a pour premier but un partage équitable des ressources matérielles de la machine entre les diverses taches du système. NICE permet d'attribuer une priorité à une tache, et de modifier cette priorité à chaud, pendant le fonctionnement de l'application. Nice agit en fonction d' un ensemble, c'est à dire qu'il gère la priorité des taches de manière individuelle, et toujours par rapport à l' ensemble des taches. Son vocabulaire va de 20 à -19 (-19 étant la priorité la plus haute et 20 la plus basse). CFS est l' ordonnanceur de Linux depuis peu [début 2008] et peut être pour longtemps. CFS (Conpletly Fair Sheduler - ordonnaceur completèment équitable)

Le temps réel en informatique pourrait être défini comme un système permettant de soumettre des taches à des notions de temps précis et choisis. C'est à dire qu'il s'agit d'un système prédictible, ou le temps d'exécution est borné.

Généralement, il s'agit de permettre aux logiciels d'avoir un traitement de l'information avec la plus faible latence possible. C'est à dire que l'ensemble "écriture de l'information, son traitement et enfin sa restitution" est effectué dans un temps faible, borné par configuration, que l'on nomme alors l'information "préservée" (le temps d'exécution global permet une restitution du résultat de l'information traitée avant que l'information initiale est pu être modifiée.

Imaginons une salle de marché ou le cours fluctue vite... chaque donneur d'ordre se doit d'être le plus réactif possible afin de faire enregistré son ordre avant toute modification du cours. Voilà un exemple concret de ce que peut être les contraintes du temps-réel : nous sommes dans une notion globale de latence et d'ensemble interagissant, avec une garantie nécessaire du temps de traitement.

Contrairement à ce que l'on pourrait penser de prime abord, un système temps réel n'est pas plus rapide qu'un système normal. Si on se place du point de vue utilisateur, au contraire, même : la rapidité d'exécution globale de l'ensemble des tâches s'en trouve diminuée. Ceci est du aux nouvelles capacités du système : la possibilité de pouvoir attribuer de hautes priorités dans le système et aussi des ressources matérielles pour les applications ayant accès aux capacités temps réel du système. Temps réel c'est avoir un système plus rapide, avoir plus de puissance, "je joue à WOW en temps réel". Cette affirmation classique est fausse.

Reprenons notre définition d'un système temps-réel : un système permettant de soumettre les taches à des notions très précises de temps d'exécution rendant ainsi la vitesse de leur traitement prédictible. Nous sommes en présence d'un ensemble prévisible selon un cahier des charges pré-défini. Par exemple la plus faible latence possible pour le traitement du signal audio-numérique et l'accès privilégié à certains ressources matérielles (occupation CPU, mémoire vive fixée et dédiée). Ces contraintes du cahier des charges appliquées au système entier auront pour effet d'obtenir en permanence voir de maintenir, un accès à ces ressources prioritaire sur tout autre. Ce qui globalement entraîne une perte de performances. Votre navigateur internet réagira bien moins vite si un traitement audio numérique est en cours avec une priorité RT. Pour nos tâches définies, ce système permet une haute priorité et un accès privilégié au ressources matérielles. Donc un gain de performances pour ces taches là, au détriment des autres.

Dans un tel système, nous voyons qu'il est primordial d'avoir un parfaite adéquation entre les ressources matérielles, le choix des accès temps réel, la configuration du système et l'utilisation de ce dernier. Vous pouvez consultez la page ProAudio pour savoir comment faire pour Jack et les applications audio.

Nous sommes à l'âge de pierre de l'informatique.~~

Il existe deux types de temps réel :

• Le temps réel dur (Hard Real Time) c'est le système répondant strictement à la définition ci-dessus. Le patch de MR Molnar, de Mr Gleixnar et de leur équipe répond à cette définition. Un contributeur Mandriva maintient un tel kernel pour Mandriva Linux. (voir ci-après)
• Le temps réel mou (Soft Real Time) un système temps réel mais s'accommodant du dépassement de contrainte de traitement. Des patchs au noyau linux sont depuis longtemps intégrés. (voir ci après)

Généralement les système temps réels sont des systèmes embarqués. Par exemple sur de petits matériels électroniques, parfaitement adaptés pour leur tache. Toujours l'adéquation entre matériel, configuration système et besoin du traitement.

Exemples de systèmes temps réel

• VxWorks : C'est le système RT le plus utilisé au monde certainement. Création de WindRiver, on peut le trouver dans de nombreux matériels qui vont dans le ciel et dans l'espace. Il réponds aux normes POSIX. (il est, de plus, le premier à proposer la gestion du réseau dans ce cahier des charges particulier).
• QNX : Originaire du Canada, également conforme POSIX et est de type UNIX. On notera la présence d'une interface graphique : Photon. Ainsi qu'une foisonnante communauté !
• WINCE : Windows CE : aujourd'hui présent pour les téléphones portables et autres.
• LYNX OS : conçue par LynuxWorks est aussi confirmé POSIX et de type UNIX. Il est également très utilisé dans le monde aéronautique.

• LINUX : Noyau et Eco-Système complet OpenSource et Libre, répondant aux exigeances POSIX. Il connaît une fulgurante ascension dans ce domaine, plus que dans tout autre. Sa modularité, sa portabilité, ses possibilités multiples et son accès aisé font qu'il est aujourd'hui massivement adopté. La société éditrice de LynxOs s'est renommé LinuxWorks et s'est totalement tournée vers Linux. WindRiver aussi, tout en continuant le support de son VxWorks, propose aujourd'hui par défaut des solutions basées sur le noyau Linux.
  • RTLINUX : première solution toute prête, elle s'est orientée aujourd'hui vers une solution privatrice (non libre et non open source).
  • RTAI : Issu de Rtlinux. RealTime Application Interface for Linux est une extension libre permettant des fonctions temps réel dur. Développée par le Département d'Ingéniérie Aérospatiale de l'école polytechnique de Milan en collaboration avec des développeurs de l'Université du Nouveau-Mexique aux Etats-Unis.
  • XENOMAI : issu de RTAI, avec les mêmes possibilités au final, il diverge par l'apport d'une couche de virtualisation complète.
    • Ces trois solutions ont en commun de considérer le noyau Linux en tant que simple tache pour un ordonnanceur, un hyperviseur, complètement temps réel. L'ordonnanceur utilise Linux pour sa grande compatibilité matérielle, et ne gère que l'ordonnancement des taches bornées temps réel.

• • Les patchs au noyau Linux :
    • Patches low latency et preemptif : Temps réel mou, permettant un traitement du signal audionumérique tout à fait correct. Egalement pour l'embarqué type téléphones portables et autres gadgets. Une des sociétés les plus célèbre est MontaVista dans le domaine. Le noyau Linux intègre depuis longtemps deux patchs :
      • Celui issu du travail de Mr Love : il agit sur l'ordonnanceur de Linux et réduit le temps de réponse de manière systématique.
      • Celui issu du travail de Mr Morton, dit "low latency" : il n'agit que sur des points précis du noyau, appelés points de préemption, afin d'améliorer précisément pour ces noeuds là le temps de latence.
    • Patche Temps-Reel Dur (preemption on acid) : issu du travail de Mr Molnar et Mr Gleixnar. Il agit sur la globalité du noyau. De nombreuses améliorations apportés par ce patch ont directement été intégrés dans le kernel. -> c'est de cette solution dont il est question maintenant, pour votre Mandriva.

[modifier] Références

• http://redhat.com
• http://kerneltrap.org/node/8059
• http://people.redhat.com/mingo/
• https://linuxfr.org//2006/09/20/21352.html
• https://linuxfr.org//2007/12/13/23447.html
• -> http://rt.wiki.kernel.org/

"Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT." -- Linus Torvalds

[modifier] Temps-réel dur pour Mandriva

[modifier] Le noyau

[modifier] Installation

Installez un noyau temps réel dur sur sa Mandriva n'a plus rien de compliqué : de tels noyaux sont maintenus par la communauté et intégré dans le dépôt officiel Contrib.

Il existe diverses saveurs de noyaux :

• En fonction de l'architecture : un pour machine mono-processeur, un autre pour machine multi-coeurs ou mutli-processeurs.
• En fonction du besoin : le noyau classique, un noyau comportant les devel, nécessaire pour que dkms recompile tout seul des modules/drivers tiers. Et les sources complètes, utiles si vous souhaitez recompiler vous même votre noyau. Enfin une version debug, si vous êtes développeurs du, ou autour du, noyau.

Installez un noyau pour une machine multi-processeur est aussi simple que :

Rappel : les rpm "latest" permettent de s'affranchir de la connaissance de la version du noyau le plus récent : celui ci sera automatiquement résolu et installé.

[modifier] Les tests

Il existe divers tests de noyau temps réel, il existe aussi des produits complets de supervision de développement, de profiling de comportement et de debugging pour le RT (tel que la suite de Conccurent Computer).

[modifier] RT-Tests

Rt-Tests est un outil développé par Thomas Gleixnar :

http://www.kernel.org/pub/linux/kernel/people/tglx/rt-tests

décompressez l'archive, puis compiler cet ensemble d' outils. Veuillez vous reporter aux informations sur ces tests pour en savoir plus : http://rt.wiki.kernel.org/index.php/Cyclictest

[modifier] PowerTop

Powertop est un outil développé par Intel pour visualiser certains comportements du système. Bien qu'il soit plus spécifiquement destiné à la gestion de l'énergie, entre autre pour des laptops, c'est ici aussi un outil à considérer dans la mesure où il va nous permettre de visualiser simplement le nombre de réveils par seconde du noyau, et quelles sont les applications les plus demandeuses. (enfin il prodigue des conseils, mais bien que judicieux, ils ne sont pas adaptés à une utilisation MAO de votre Mandriva linux. Exemple de conseil inutile pour nous ici : echo 1 > /sys/module/snd_ac97_codec/parameters/power_save...)

On peut observer ici la valeur Wakeups-from-idle per second qui donne un résultat de 1500 soit plus de 1500 réveils du noyau sur un intervale de 3 secondes, soit plus de 500 réveils par seconde. Puis on peut observer le pourcentage pour chaque application de ces réveils. Par exemple ici on voit que projectM-jack et do_nano_sleep sont les deux principales causes de ces réveils.

[modifier] LatencyTop

LatencyTop est un outil développé par Intel pour visualiser certains comportements du système. Permet de visualiser le comportement du système entre les demandes des applications et les ouverture du noyau pour elles. Cet outil est disponible sous forme de patch à appliquer d' un côté, et un d' un programme à compiler d' un autre. Veillez à utiliser la même version de noyau et de patch, tout comme le -rt.

[modifier] LMbench

LMbench est un outil développé par BitMover (éditeur aussi de BitKeeper, l' ancien gestionnaire de version concurrentes utilisée par linux, remplacé par git.). Cet outil est disponible sour forme d' un programme à compiler. Puis un "make result" lancera l' ensemble des tests disponibles. Veuillez vous reporter à la documentation de LMbench pour ne lancer que certains tests.

[modifier] Le système

[modifier] PAM

Il faut maintenant permettre à un utilisateur spécifique, ou à celui courant, ou à un groupe, d'accéder à ses nouvelles possibilités du système. Ceci se fait par le biais de PAM, qui sécurise la configuration de cela également.

Ce fichier comporte la quasi totalité des informations nécessaires à connaître pour en comprendre le fonctionnement. Résumons les éléments primordiaux :

• le symbole arobase précède le nom audio, il sera donc interprété comme le "groupe audio"
• Le symbole entre @audio et rtprio est "-" il désigne que nous voulons à la fois hard et soft.
• La première valeur est la plus important, elle désigne la priorité que l'on souhaite attribuer à ce groupe : 99 est un bon choix ici.
• La seconde valeur attribue le "nice", la commande usuelle pour attribuer une priorité dans l' ordonnancement des taches entre elles. Son vocabulaire va de -20 qui est la plus forte priorité, jusqu'à 19, la plus faible.
• La dernière valeur indique la mémoire vive à "réserver" pour cela, ici "unlimited".

Exemple de configuration du fichier, pour l'utilisateur "sumo" pour une machine disposant de :

• 2 processeurs Xeon 3,06GHZ
• 3GO de ram ECC

sumo            -       memlock         unlimited
sumo            -       rtprio          99
sumo            -       nice            -19 

[modifier] ACPI

L'acpi est fortement déconseillée. Il convient de retirer ce service du système, il peut être source de latence. Et puis c'est toujours plus sympa pour éteindre vraiment un ordinateur d'appuyer sur un vrai bouton. Enfin il va de soi que des fonctions comme le suspend to ram ou to disk sont à proscrire.

ps : sur un système "MAO", vous pouvez tout à fait laisser l' ACPI : assurez vous simplement que le processeur ne change pas de fréquence : toujours la maximale. Et conserver toutes les autres fonctions acpi.

[modifier] USB

L'usb peut également être source de latence (noyau), sur un système temps réel pur il conviendra de retirer le support de l'usb dans le bios directement si votre pc ressemble plutôt à une machine embarquée qu' à un pc...

[modifier] Conclusion

Que vous soyez fans de robots, électroniciens plein de talent, audiophiles exigeants, ou simplement curieux de nouvelles découvertes :

Amusez vous bien sur Mandriva Linux.