Re: [assoce magnum] Ordre du jour 25/04

[yvan <bubar@xxxxxxxxxxxxx>]

Le Monday 14 April 2008 09:50:28 pm Olivier FAURAX, vous avez écrit :
> - Magnum : Ash m'a vu sur Jabber et m'a dit qu'ils sont un peu court au
> niveau contenu et que la motivation du début se tasse. Ça serait sympa
> de savoir exactement ce qu'il faudrait comme article (taille, thème),
> pour que des personnes présentes à la réunion puisse proposer des articles.

Bonjour,

Je profite de la ML pour proposer un article généraliste sur le temps-réel :
vous trouverez, en pièce jointe dans le fichier texte, les grandes lignes.
Ce texte n' est qu' un simple copier coller de l' ancienne page Audio du wiki 
(trop longue, trop lourde, pourtant manque d' éléments, elle est en refonte 
ici en local pour le moment)

Cet article peut être un début pour ensuite, dans le numéro suivant, faire un 
article sur le son, les spécifiqtés de Spring et des généralités de 
fonctionnement, puis des généralités avec linux.

Vous noterez que ces articles ne sont pas "finis", que le premier a juste 
besoin d' une petite ré-hausse et de quelques ajustements. Quant au second, 
le mieux est certainement que je le publie sur le wiki afin que tout le monde 
corrige et ajoute des choses. 

Voilà, si ça peux remplir un peu le contenu de votre futur magnum (?) il est 
probable que des notions généralistes soient appréciés des lecteurs.

Ca fait un moment que ça traine, le fait qu' un article sur PulseAudio soit 
écrit pour le prochain numéro peux faire une continuité intéressante.




 
=== Notion de temps, notions de latences ===

==== Latences ====

On définie usuellement la latence comme étant le temps entre une action et la réaction engendrée par l'action. C'est également le cas en informatique et en « musique assistée par ordinateur ».

[[image:lat2.png|left|]]

La latence c'est grosso modo le temps nécessaire au matériel informatique pour traiter un signal audio qu'il reçoit. La latence est perceptible quand par exemple on branche une guitare ou un piano sur l'ordinateur et que le son produit est décalé. Décalé entre le son réel qui sort du piano ou de la guitare et celui qui sort des enceintes de l'ordinateur.

La notion de « tampon » (buffer) se retrouve partout, à tout les niveaux :

même purement matériel. Une carte son à une latence en entrée par exemple. C'est à dire que pendant que un tampon est lu, un autre est rempli.

En terme informatique on appelle "IRQ" (attention ce terme n'est ni spécifique ni parfaitement résumé et défini ici) la capacité du système à servir les requêtes des périphériques en entrée et en sortie.

L'image suivante montre comment on peut présenter cela le plus simplement possible.

Des temps de décalage sont également audibles si l'ordinateur est très occupé à faire quelque chose et doit dans le même temps produire un son, une musique à écoutée. On entendra alors une série de blancs successifs qui hacheront le morceau et rendront son écoute bien inconfortable. Sur un bureau multimédia la solution courante est d'avoir un « tampon » audio : c'est à dire une « mémoire », une "swap" sur laquelle l'ordinateur va stocker les informations avant de les restituer sur les haut-parleurs, la sortie standard. Cela permet un grand confort. Par exemple arts peut être configuré pour agrandir son tampon audio, ce qui va résoudre ces "blancs" lors de lectures sur de petits ordinateurs ou sur des machines très occupées à faire autre chose.

Mais si cette solution convient tout à fait pour le bureau multimédia de Mr-tout-le-monde, il est logique qu'il soit en décalage avec une demande de jouer un son de guitare ou de piano pour un enregistrement studio… Si le tampon est de grande taille (donc plus long à remplir), la sortie du traitement du signal n'en sera que plus décalée dans le temps et les musiciens vont avoir toutes les difficultés du monde à entendre ce qu'ils jouent vraiment. Pour grossir, un exemple : imaginez que vous branchiez votre guitare sur l'ordinateur, qu'un ami branche sa basse et que chacun soit muni d'un casque relié à ce même ordinateur : le but étant de jouer ensemble pour enregistrer un morceau et d'avoir le retour dans son casque de ce que l'on joue. Grossissons le résultat : je gratte une corde et mon ami aussi sur sa basse : j ai un décalage de 1 seconde dans mon casque sur ce que je joue (pas bon) et dans le même temps j'entends ce que joue mon ami avec un décalage de 2 secondes (pas bon non plus)… Il va devenir très… heu… sportif de jouer dans ces conditions.

===== Notion de gestion des process dans le système =====

Un système informatique c'est tout plein de trucs partout qui tournent en même temps !

Considérons le système informatique comme un ensemble de processus permettant de gérer du matériel. Cet ensemble nécessite de l'ordre : deux processus se tapant dessus pour obtenir un accès rapide et élevé sur le processeur central pourraient bloquer tout les autres.

Il y a beaucoup de gestion différentes permettant de mettre de l'ordre dans tout cela. Survolons ici "nice". Par exemple sur une Mandriva, lancer une compilation ne pose aucun soucis par défaut! Parc eque le process de compilation reçoit une attribution de basse priorité : il est donc aisé et agréable de faire du développement et de la compilation sur un tel système : On peut continuer sereinement une autre tâche pendant que la première est en train d'être compilée. C'est qu on appelle la courtoisie (nice) d'un processus.

Nice est une commande avec un vocabulaire spécifique allant de -20 (la plus haute priorité) à +19 (la plus basse priorité). Et c'est l'ordre général des "nice" des process qui va réguler l'ensemble. Exemple grossi : un process ayant une courtoisie de -10 tournant parmi plein de process ayant une courtoisie de 0 sera prioritaire. Si un autre process est lancé, mais avec une courtoisie de -15, il sera prioritaire sur tout les autres. Et celui avec -10 restera prioritaire sur ceux ayant 0. C'est donc un système modulant l'attribution des temps de fonctionnement à un ensemble de processus dont chacun à un attribut personnel servant à le classer dans cet ensemble.

===== Notion de latence dans le noyau =====

Le noyau linux est taillé par défaut pour la sécurité pleine et entière du système. Il est possible avec Linux d'aller encore bien au-delà (rsbac / grsecurity ; selinux ; … etc). Par défaut tous les process doivent passer par d'énormes 'commissariats'(ordonnanceurs) qui se chargeront de vérifier leurs demandes puis les laisseront accéder au matériel, par exemple la mémoire vive, et en plus selon des procédures strictes de qu'ils ont le droit de faire ou pas, pour cet accès. Ces systèmes sont logiquement sources de latence. Mais il ne sera pas nécessaires de les mettre de côté (contrairement à d'autres OS). Nous pouvons conserver ces sécurités pour l'ensemble du système tout en autorisant un accès privilégié pour certains process, et uniquement ceux là. Tout en restant dans un cadre Linux (gestion mémoire vive, etc..)

C'est la notion de "low-latency" (faible latence). Nous verrons plus loin qu'il existe des kernels multimédias précompilés, et la manière de les utiliser. Nous aborderons également la configuration optimale de l'ensemble du système pour ces noyaux faible latence, afin de préserver la sécurité intrinsèque de Linux. Enfin, nous verrons comment utiliser un panel applicatif sur cet ensemble.

Pour terminer, nous verrons comment recompiler facilement un noyau dit "vanilla" pour sa mandriva, en le préparant au préalable avec le patch RealTime de Sir Ingo Molnar : afin d'obtenir un système, disons le ouvertement, faisant pâlir d'envie tout autre système...

===== Notion de latence dans le matériel =====

Revenons un petit peu sur les IRQ. Sur un système taillé pour la M.A.O. il sera nécessaire de jeter un oeil au bios, afin de s'assurer de l'absence d'irq partagées pour la (les) carte(s) son(s).

Irq signifie Interrupt ReQuest, interruption matérielle en Français. Sur un ordinateur dont l'architecture est x86, il y a 15 irq possibles directement accessibles pour et par des événements externes. La numérotation de celles-ci correspond à la priorité accordée par la machine pour chacune: irq11 est prioritaire sur irq15, et irq0 est prioritaire sur toutes.
(En fait l'ordre des irq est un peu plus compliqué puisque les irq 9 à 15 sont attachées, pour des raisons matérielles historiques, à l'irq 2, ce qui donne l'ordre suivant:  0 > 1 > 8 > 9 > 10 > 11 > 12 > 13 > 14 > 15 > 3 > 4 > 5 > 6 > 7

Nous reviendrons également sur certaines finesses de configurations, car il est important que votre (ou vos) carte(s) son bénéficie(nt) de la meilleure priorité ici aussi.

La notion de temps est intrinsèquement une notion primordiale dans un système d'exploitation. Le temps en tant que tel, l'horloge en tant que coeur, est devenu un élément fondamental.

A partir du moment où il est devenu nécessaire de lier un simple calcul avec une simple horloge, cette notion s'est imposée en informatique comme pièce maîtresse. Bien que non indispensable, pour par exemple un système dédié au calcul pur, elle devient intéressante dès que plusieurs calculs doivent être effectués simultanément.

Tout les systèmes informatiques modernes sont multi-tâches. Certains ont plus de mal que d'autres, certes, mais ce n'est pas le sujet. GNU/Linux est complètement et efficacement multi-tâches. De plus il est multi-utilisateurs. L'ordonnancement des tâches entre elles doit donc être conçue afin de permettre à l'utilisateur humain de conserver un confort lors de l'exécution d'applications. Cela est assuré par un ordonnanceur, scheduler, qui va se charger de partager pour chacune des tâches les ressources matérielles disponibles. C'est ici la notion de TEMPS PARTAGE.

==== Temps ====

===== Le Temps Partagé =====

Certains systèmes d'exploitation font le choix de donner de hautes priorités à des tâches complètement secondaires pour le calcul, néanmoins "primordial" du point de vue du "bug entre le clavier et l'écran".

D'autres systèmes, tels les UNIX, font le choix de toujours conserver un haut niveau de priorité pour les tâches fondamentales, assurant ainsi à l'ensemble une cohésion globale et une forte tenue à la charge multi-tâches. Au détriment bien sur de tâches moins importantes du point de vue système comme par exemple l'affichage d'une page web ou la lecture d'un son du bureau.

Il est aujourd'hui évident que ce dernier choix est le bon choix, et même les utilisateurs finaux préfèrent maintenant un décalage entre une popup d'avertissement et le son l'accompagnant, mais un système global fiable avec moultes applications ouvertes. Plutôt qu'une impression de confort sur des tâches secondaires mais un système peu fiable dans sa globalité.

L'ordonnanceur a donc pour premier but un partage équitable des ressources entre les diverses tâches. Pour compléter ce dispositif plusieurs briques sont là. La plus connue, la plus courante est '''nice'''sous linux. Comme cela a été dit plus haut, nice est là pour attribuer des priorités. Nice agit en fonction d'un ensemble, c'est à dire qu'il permet la gestion des priorités des tâches l'une par rapport aux autres et non de manière absolue.
La pré-configuration d'une Mandriva-Linux permet un grand confort de ce point de vue.

Ensuite il y a la notion de ressources partagées : par exemple un accès en écriture sur le disque dur entraîne nécessairement, par limite physique, un laps de temps avant un autre accès. La disponibilité de ce matériel n'est donc que peu prévisible. Pour compléter cet exemple 'hardware', la mémoire virtuelle, ou 'swap'engendre quant à elle  également des accès disque et sera donc également source de latence.

===== Le Temps-Réel =====

[[image:clock.png|left|]]

Le temps réel en informatique pourrait être défini comme un système permettant de soumettre les tâches à des contraintes de temps précises et choisies. C'est à dire qu'il s'agit d'un système prédictible, dans le sens où on est sûr (autant qu'on puisse l'être en informatique) qu'un événement entraînera un traitement par le système dans un temps maximal défini.

Généralement, il s'agit de permettre aux logiciels d'avoir un accès aux matériels 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 si faible qu'on nomme l'information comme « préservée » (le temps d'exécution global permet une restitution du résultat avant que l'information initiale ait pu être modifiée. Imaginons une salle de marché « à la criée » ou chaque donneur d'ordre se doit d'être le plus réactif possible afin de faire enregistrer son ordre avant que le cours se modifie. Voilà un exemple concret de ce que peuvent être les contraintes du temps-réel : nous somme toujours dans une notion globale de latence et d'ensemble interagissant.

[[image:QuartzCrystalSml.png|left|crystal de quartz]]

[[image:silicium.JPG|right|crystal de silicium]]

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 linux classique. Au contraire, un ensemble noyau+système+applications pour le traitement du signal audio-numérique par exemple, a une rapidité d'exécution globale plus faible qu'un système classique. Les solutions temps-réel entraînent une perte de performance globale.
Ceci est dû aux nouvelles capacités du système : la possibilité de pouvoir attribuer de hautes priorités d'accès à certaines fonctions entraîne nécessairement des accès différemment agencés. ''Tuons immédiatement le troll « être temps-réel c'est avoir beaucoup de puissance ». Non.''(Par contre une grande puissance matérielle facilite le temps réel.)

Reprenons notre simple définition d'un système temps-réel : un système permettant de soumettre les tâches à des contraintes précises et choisies de temps d'exécution rendant ainsi le système prédictible. Nous sommes en présence d'un ensemble prévisible selon le cahier des charges pré-défini : par exemple la plus faible latence possible pour le traitement audio et l'accès aux ressources matérielles inhérentes. Ces contraintes de notre cahier des charges appliquées au système temps réel auront pour effets d'obtenir en permanence, voire de maintenir, des accès (au processeur, à la mémoire vive, aux matériels) prioritaires sur tout autre. Il y aura donc pour ces autres  tâches des accès sur moins de ressources et moins vite. Ce qui, globalement, entraîne une perte de performance. Néanmoins, pour nos tâches définies, il y a non seulement haute-priorité de traitement mais également gain de performance.

Dans un tel système, le matériel doit être conforme au cahier des charges. Pour une solution MAO, il conviendra d'avoir cependant le meilleur matériel possible, par exemple un processeur central cadencé à plus de 1.5 giga-hertz ainsi qu'une quantité de mémoire vive suffisante.

Note hautement copyrightée depuis 10 ans par l'auteur , brevet détenu, tout droits réservé :) Nous sommes à l'age de pierre de l'informatique.

En pré-conclusion, prenons en exemple une tâche devant s'effectuer à intervalles réguliers :

Sur un système classique, cette tâche s'exécute avec une latence précédant son lancement. De plus cette latence est soumise aux contraintes du moment de son exécution (charge processeur, occupation de la mémoire vive). Enfin, dans ce contexte, la latence sera régulée par la priorité donnée à cette tâche, son "nice". La latence est donc toujours présente et est en plus non prévisible.

Sur un système temps-réel, si cette tâche a droit au temps-réel, elle s'effectue en fonction d'une valeur de temps donnée, fixe et maximale. Elle est donc bornée et forcément inférieure à cette valeur. Elle bénéficiera en plus d'un accès privilégié et obtiendra donc globalement une latence la plus faible possible (exprimée en micro-secondes) Cette tâche devient prédictible.

'''Deux types de temps réel'''

''le temps réel dur'': (hard real time) c'est celui répondant strictement à la définition ci dessus. C'est à dire qu'il ne dépasse strictement pas les limites imposées par le cahier des charges, par la configuration voulue.

''le temps réel mou'': (soft real time) un système temps réel mais s'accommodant de dépassement de ces contraintes.

==== Quelques exemples de systèmes temps-réel ====

* VXWORKS :

C'est le système temps-réel le plus utilisé au monde. Création de "WIND RIVER" on le retrouve dans la quasi-totalité de tout ce qui, par exemple, vole dans l'air ou va dans l'espace. C'est un système taillé pour l'embarqué (cad : hardware minimal et taillé pil poil aux besoins), il est conforme et réponds aux normes POSIX. (il est de plus, historiquement, le premier à proposé la gestion du réseau dans ce cahier des charges particulier)

* QNX :

Originaire du Canada, un autre système temps-réel taillé pour l'électronique embarquée. Il est également conforme POSIX et est de type UNIX. On notera la présence d'une interface graphique possible ( de type Xorg) : Photon, ainsi qu'une foisonnante communauté.
(anecdote non vérifiée : on murmure que des développeurs de feu Amiga auraient rejoint ces deux systèmes)

* WINCE :

Windows CE, annoncé comme révolutionnaire à grand coup de marketing, a fait flop. Et la récente ouverture de ses sources a précipité sa chute : le monde l'open source est sans pitié du point de vue de la concurrence commerciale (pourquoi l'utiliser s'il faut refaire tant que ça dedans ?). aujourd'hui cantonné aux téléphones portables et autre gadgets.

* LYNX-OS :

conçu par "LynuxWorks" est également un système conforme POSIX et de type UNIX. Est également très utilisé, en aéronautique entre autre.

* '''LINUX''':

Système Open-Source répondant aux exigences POSIX, connaît une fulgurante ascension (bien plus encore que sur tout autre marché, serveurs y compris !) Sa modularité, ses possibilités multiples d'adaptation font qu'il est aujourd'hui adopté massivement. La société ayant conçu LynxOS s'est complètement orientée vers lui et s'est renommée "linuxworks". WindRiver, tout en continuant le support pour son vxworks, propose aujourd'hui majoritairement des solutions standards autour de linux.

* RTLINUX : première solution « toute prête » (restant bien sûr adaptable à volonté de par la nature open-source du projet initial), elle s'est orientée aujourd'hui vers une solution non-open-source (closed source). Ce qui a amené la communauté de développeurs actifs à la délaisser, puis finalement les clients ont fait de même.
* RTAI : Issu de rtlinux. RealTime Application Interface for Linux est une extension libre pour Linux lui permettant des fonctions temps-réel dur. (Développée au départ par le département d´ingénierie aérospatiale de l´école polytechnique de Milan en collaboration avec un développeur de l'université du Nouveau-Mexique aux États-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 linux en tant que noyau indépendant : leur "patch", "solutions" (plus ou moins évoluées) résidant toutes les trois sur l'apport d'un micro noyau au côté du noyau linux (ou plutôt, plus précisément, un ordonnanceur complètement temps réel). L'ordonnanceur considère alors linux en faible priorité, auquel il va déléguer la majorité des tâches à exécuter, lui-même ne s'occupant alors que des tâches temps-réel dur (l'auteur avoue sa préférence pour l'élégance de cette solution, en particulier pour Xenomai).

* LES PATCHS Ils vont permettre au noyau Linux lui-même de devenir temps réel. Ce sont ces solutions que nous allons retenir pour le cadre MAO.

Là encore, le marché foisonne de solutions diverses conçues pour des besoins précis, chacune restant adaptable au gré des évolutions de ces besoins. Une des sociétés les plus actives et célèbres dans ce domaine est MONTAVISTA, spécialisée dans l'embarqué haut de gamme (high end). Le patch le plus célèbre est écrit par SIR INGO MOLNAR lui-même.

* Les patchs "low latency" & "préemptifs" :

Il s'agit pas de temps-réel dur, mais de temps-réel mou (comme sous apple osX) permettant une gestion et un traitement du signal audionumérique tout à fait correct. Egalement pour l'embarque types gadgets (téléphones portables...) C'est aussi la solution retenue et développée par MontaVista. On peut distinguer 2 types de patchs :
celui issu du travail de Mr Love, dit patch "préemptif" : 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 patch "low-latency" : il n'agit que sur des points précis du noyau, appelés "point de préemption" afin d'améliorer précisément pour ces noeuds-là le temps de latence.

* Les patchs "temps-réel dur !" :

C'est la solution que nous expliquerons dans le chapitre « pratique ». C'est la solution maintenue par Ingo Molnar. Ce patch est assez récent et peut être appliqué à chaque version du noyau (une version spécifique pour chaque étant disponible) sur la majorité des kernels de la série 2.6. Il transforme complètement le noyau en noyau temps-réel dur, avec sécurité du « chien de garde » et en ajoutant une horloge aux performances nettement supérieures à celle d'origine.