RTAI est un fork de RTLinux qui permet de s'affranchir des problèmes de licences liés à celui-ci.
L'originalité de ce projet est qu'il permet d'obtenir d'une machine un comportement temps réel dur (n'ayant rien à envier à ses concurrents propriétaires) tout en gardant le comportement temps partagé du noyau linux.
Note du modérateur : la version précédente datait du mars 2003 Les contributeurs se focalisent principalement sur le développement d'où des manques certains dans le maintien du site et de la documentation.
Ces inconvénients sont largement compensés par une liste de diffusion très réactive.
Une distribution RTAI se présenté sous la forme de patchs pour différentes version du noyau linux et des sources de RTAI lui-même.
Pour ceux qui connaissent RTLinux, RTAI permet en plus d'écrire des tâches temps réel dur dans l'espace utilisateur.
Aller plus loin
- DIAPM RTAI (8 clics)
- Applications (12 clics)
# temps réel dur ?
Posté par CopainJack (site web personnel, Mastodon) . Évalué à 6.
Merci.
(des liens, c'est bon aussi)
[^] # Re: temps réel dur ?
Posté par ASpirit . Évalué à -3.
loc. m.
[SYSTM] Abrégé en TR. Se dit d'un système devant répondre aux sollicitations de son environnement physique dans des délais précis, ou d'un système devant simuler le fonctionnement d'un autre système, à la même vitesse que ce dernier. Un modèle météorologique en temps réel serait complètement crétin pour prédire le temps !
Le temps réel repose sur trois notions fondamentales : le parallélisme (multitâche pour exécuter un programme indépendamment de tout autre), le respect des échéances et le couplage des tâches (© LMI).
Le temps réel est dit « mou » s'il a un temps de réponse de l'ordre de 0.5 secondes. Il est dit « dur » si ses délais sont plus courts. Voir aussi HRT, ROOM.
Articles liés à celui-ci :
à la volée BeOS CHILL clavarder doubleur eCos HRT IRTOS IVI jardiner MAP MGR netlag O OS/9 PDP-x PLV POSIX RSVP RTEMS RTP RTS SML Spox streaming TR visiophonie voxel
Articles voisins :
temporiser - temps d'accès
- temps de réponse
- temps inactif
- temps partagé - TEOTWAWKI - TEP - térabit - téraflop - Téraflop Club
http://tout-savoir.net/lexique.php?rub=definition&code=7416(...)
[^] #
Posté par Francois Revol (site web personnel) . Évalué à 7.
Un système temps-réel doux "fait de son mieux" pour répondre aux exigences des applications.
Un système RT "dur" quand à lui *garanti* qu'il répondra dans les temps qu'on lui demande (pourvu qu'il soit d'accord avec les contraintes demandés).
[^] #
Posté par Francois Revol (site web personnel) . Évalué à 7.
[^] # Re: Sortie de RTAI 24.1.12
Posté par Moby-Dik . Évalué à 4.
Imaginons un petit appareil (genre machin ultra-portable pour jeunes branchouilles) comportant 16 Mo de DRAM rapide et 512 Mo de mémoire Flash utilisée comme ramdisk/pagefile... C'est réaliste ? C'est utile ?
[^] # Re: Sortie de RTAI 24.1.12
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Sortie de RTAI 24.1.12
Posté par wistily . Évalué à 1.
[^] # Re: Sortie de RTAI 24.1.12
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 3.
1 - c'est une carte mémoire amovible (SD Card, Memory Stick)
2 - c'est un produit à faible potentiel de vie (un téléphone mobile est PRÉVU pour être changé au boût de deux ans, une limitation des cycles de vie de batterie le garantissant)
3 - c'est une mémoire qui est rarement modifiée (BIOS d'une carte-mère d'un pc)
[^] # Re: Sortie de RTAI 24.1.12
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Ne serait-ce que pour le cache du processeur, en général, on parle en WCET (Worst Case Execution Time), et le pire cas, c'est un défaut de page. Du coup, le calcul du pire cas pour un processeur avec cache est pire ou égal à celui d'un processeur sans cache.
Sinon, il faut être capable de dire à l'avance si il va y avoir un défaut de page ou pas. Il y a des gens qui travaillent dessus (pour le cache instructions. Pour les données, c'est carrément infaisable), mais c'est un problème difficile.
[^] # Re: Sortie de RTAI 24.1.12
Posté par PachaFonk . Évalué à 1.
Donc c'est faisable (et facile) avec RTAI.
De plus, dans un developpement RTAI, les traitements qui ont des besoins tres fort en terme de temps de latence (temps de reaction a une interruption) sont ecris comme des modules du noyau... donc la memoire qu'ils utilisent n'est pas swapee.
C'est probablement la facon la plus simple (et la plus sure) de s'afranchir des problemes de swap... en contrepartie, les besoin en ressources doivent etre bien connus...
[^] # Re: Sortie de RTAI 24.1.12
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: temps réel dur ?
Posté par chl (site web personnel) . Évalué à 6.
Sommaire d'un chapitre d'un cours temps reel :
http://www.rennes.supelec.fr/ren/perso/pchlique/tpsreel/acctr.htm(...)
temps reel souple :
http://www.rennes.supelec.fr/ren/perso/pchlique/tpsreel/trmou.htm(...)
temps reel dur :
http://www.rennes.supelec.fr/ren/perso/pchlique/tpsreel/trdur.htm(...)
[^] # Re: temps réel dur ?
Posté par dinomasque . Évalué à 3.
Tout ce que je sais du sujet vient de la "propagande BeOS".
Pour un poste de travail domestique classique, quels sont les avantages ?
- vidéo plus fluide ?
- traitement du son ? création musicale ?
- jeux plus "multimédia" ?
- applications bureautiques plus rapides ?
- retour de l'être aimé, accroissement pénien, repousse des cheveux, chance aux jeux et aux examens ?
BeOS le faisait il y a 20 ans !
[^] # Re: temps réel dur ?
Posté par ASpirit . Évalué à 1.
[^] # Re: temps réel dur ?
Posté par Jimmy . Évalué à 4.
Quand on entend parler de "bourse en temps réel sur Internet", ca me fait rire ... y'a rien de temps réel là dedans.
Dans le domaine des systèmes industriels régnent en maitres les OS propriétaires, les OS "maison", voire même pas d'OS du tout (chaque tâche est activée par une interruption). Mais Linux est en train de boulverser tout ce petit monde : pourquoi developper un OS "maison" quand on a les sources d'un OS tout fait, qui marche, il "suffit" de le rendre temps réel.
Je pense qu'après les serveurs, c'est par l'embarqué que Linux se diffuse le plus largement.
En ce qui concerne les sources d'infos, je conseille tout particulièrement :
http://www.linuxdevices.com(...)
(du PDA au gros Cluster, tous les Linux embarqués, avec des études de marchés très intéressantes, et un joli comparatif linux 2.4 / 2.6)
http://www.enseirb.fr/~kadionik/(...)
(Site d'un universitaire français, qui regorge de liens et de cours sur Linux, les systèmes embarqués, et ... Linux embarqué ! )
Juste un précision sur RTAI : c'est effectivement un fork de RTlinux, mais qui est exempt du problème de brevet logiciel qui accable ce dernier ;-)
JiM
[^] # Re: temps réel dur ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Il ne faut pas oublier un autre bordelais, pionnier de Linux, Pierre Ficheux qui a écrit "Linux embarqué" publié chez Eyrolles.
Grâce à eux, il existe une documentation de qualité en français sur le sujet.
[^] # Re: temps réel dur ?
Posté par ham . Évalué à 5.
- voiture (control des frein par exemple)
- avion , fusée, sonde spatial,...etc
- plus généralement des applications mettant en jeu la vie d'humains
- systeme de control industriel (l'application qui control la loupe pour graver des processeurs,...etc
- centraux telephonique, ... etc
[^] # Re: temps réel dur ?
Posté par PachaFonk . Évalué à 7.
On n'a rien a attendre en termes de performance pure par rapport a un systeme temps partage (au contraire...).
L'interet d'un OS temps reel est qu'il te garantie les temps de reponse.
Les contraintes d'un OS temps partage - linux, par exemple - sont pricipalement tournee vers l'agrement de l'utilisateur.
Les contraintes d'un OS temps reel son quand a elle tournee vers le processus (au sens large) a controler.
[^] # Re: temps réel dur ?
Posté par LLG . Évalué à -3.
C'est donc brevetable au sens rocardien du terme!
==>[]
[^] # Re: temps réel dur ?
Posté par romain . Évalué à 3.
[^] # Re: temps réel dur ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
[^] # Re: temps réel dur ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
En effet, que xmms ferme son clapet en 800us au lieu de 300 ms, on s'en fout un peu. Par contre, qu'il est le hoquet parce que je secoue une fenètre (de mon window manager, hein...), ça c'est hors de question.
Un logiciel temps réel se soucie plus d'une date limite dans le temps, que réellement la quantité de travail à faire. C'est la différence entre la bande passante et la latence, la quantité de travail et au bout de combien temps il sera fait.
L'informatique d'aujourd'hui est plutot en "best effort". On fait au mieux. Ton serveur web est dessiné pour fournir en moyenne 30 requètes/sec. Il n'est pas fait pour garantir une réponse à toutes requètes en 10 ms. Cela pourrait être utile pour les jeux par exemple.
"La première sécurité est la liberté"
[^] # Re: temps réel dur ?
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Par contre, quand il s'agit de matériel, si tu as un capteur qui t'envoie une donnée toutes les 100 ms, si tu ne veux pas en rater une, il faut faire attention à ce que tu fais.
[^] # Re: temps réel dur ?
Posté par dinomasque . Évalué à 2.
BeOS le faisait il y a 20 ans !
[^] # Re: temps réel dur ?
Posté par reno . Évalué à 1.
Il y a des versions gratuites qui doivent encore se trouver (attention il faut avoir moins d'1Go de RAM à cause d'une limitation du noyau).
Je ne sais pas sur quel argument marketing, tu es tombé, mais BeOS était très agréable d'utilisation:
- le système était très fluide, on était quasiment jamais bloqué.
- C'était l'installation (avec du matériel compatible malheureusement quand même assez limité) la plus facile et rapide que j'ai jamais vu.
- le temps de boot était vraiment très rapide (10-20s me souvient plus exactement du chiffre) et le système utilisable juste après le démarrage.
Alors quand on me parle du boot rapide de WindowsXP, je rigole.
Ce qui me fait moins rire, c'est que Linux est encore plus lent à booter..
Pourtant si BeOS l'a fait, c'est que c'est possible!!
Le gros point faible était le peu d'application qui existait, ça l'a tué..
[^] # Re: temps réel dur ?
Posté par LeMagicien Garcimore . Évalué à 1.
[^] # Re: temps réel dur ?
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 2.
Ces systèmes (Be, QNX) ont déjà un énorme avantage sur linux : une meilleure gestion vidéo et ce qui s'en suit (pas de quadruple transcodage de palette de couleurs, pas de gestion de polices à la c*n, pas de multiples systèmes de gestion du son,...). Mais ils n'ont pas été conçus pour être aussi versatile.
Ce qui intéresse les fabricants, c'est que Linux embarqué ou Linux sur PC, les sdk sont franchement proches. Donc c'est autant de gagné en stadardisation et en temps de dev.
Et puis, mine de rien, Linux est plus fiable que d'autres. Sendo l'a amèrement essayé : Linux lui ne tentera pas de te mettre un poignard dans le dos, c'est un partenaire FIABLE.
[^] # Re: temps réel dur ?
Posté par MaVaTi_ . Évalué à 2.
[^] # Re: temps réel dur ?
Posté par Olivier Jeannet . Évalué à 1.
C'est n'est pas du pooling (regroupement, mise en commun) mais du polling (interrogation régulière, attente active).
Bon tu n'es pas le premier à confondre les deux (au moins pour l'orthographe).
[^] # Re: temps réel dur ?
Posté par plagiats . Évalué à 3.
D'autres applications ? sans doute en labo pour calculer en combien de temps une réaction se produit après injection d'un produit, par exemple. Mais ce n'est qu'une supposition.
Bien à vous
plagiats
[^] # Re: temps réel dur ?
Posté par Dies Irae (site web personnel) . Évalué à 4.
De nombreux avions sont équipés s'un sytème "fly by wire" qui corrige en temps réel (il vaut mieux! :) les actions du pilote. Imaginons que le système reçoivent de nouvelles informations tous les 10e de secondes (valeur totalement arbitraire). Si l'avion commence à piquer du nez (-5°) il faut que le système corrige la trajectoire en bougeant les ailerons de +5°. Si le système ne répond pas dans le temps imparti alors il va recevoir à nouveau l'information -5° qu'il va corriger à nouveau. L'avion va donc se redresser de 5+5 soit 10°.
C'est un exemple assez simpliste mais ça montre l'importance du temps réel "dur" dans certaines applications critiques.
[^] # Re: temps réel dur ?
Posté par animal_omega . Évalué à 3.
http://linuxfr.org/comments/226351.html(...)
l'interet du temps reel sur cet appli est de pouvoir garantir une precision de traitement au 1/24 sec, L'application d'un filtre necessite une precision à l'image près.
donc une partie RTLinux qui s'occupe des fonctions critiques (recuperation du timecode, synchronisation du betacam, envoit des infos sur les filtres) et une partie moins sensible (GUI) qui est affiché/raffraichis quand la partie RTLinux se tourne les pouces.
[^] # Re: temps réel dur ?
Posté par B. franck . Évalué à 2.
que tu as envie de regarder un divx pendant la compilation
sur un p2@266MHz, il vaut mieux avoir un noyau "patché rt"
pour garder la fluidité de l'action
ps: par contre, il faut pas être pressé pour la ciompilation...
# Re: Sortie de RTAI 24.1.12
Posté par cassecou . Évalué à 7.
=====[]=> (je vole, à travers)
# Restons français!
Posté par lom (site web personnel) . Évalué à 4.
En français, ça ne veut pas dire grand chose, c'est juste une traduction malheureuse de hard real time.
Je trouve que temps réel strict ou souple (pour soft real time) est plus parlant et compréhensible.
Comme il est dit dans le commentaire http://linuxfr.org/comments/290325.html(...) le temps réel strict garantit un temps de réponse strictement défini et connu, tandis que le temps réel souple s'accorde plus de souplesse, et fait seulement de son mieux.
# Re: Sortie de RTAI 24.1.12
Posté par snurpsss . Évalué à 2.
C est cette garantie qui me gene , sachant que le noyau linux etant en GPL , rien n est *garantie* .
Ok je vous arrete tout de suite , pas question de me redire qu une garantie de tps c est pas pareil qu une garantie de résultat . Mais ca pose le problème suivant .
Avec un noyau TR proprio, un defaut de conception/effet de bord etc lorsqu'il entraine la perte du temps reel cause les memes pertes qu avec un noyau libre . Avec le noyau libre , l entreprise qui subit les pertes ne pourra se retourner vers personne . Alors qu'avec un noyau proprio elle pourra faire "jouer sa garantie" si je puis dire .
Peux etre est ce que je me trompe et que dans la réalité un OS tps réel libre est interressant pour les entreprises developpants des OS temps reel où en utilisant . Mais comme il s agit souvant de situation où justement c est la garantie qui importe , je me demande simplement si avant de vouloir *garantir* du tps réel il ne serai pas meilleur de *garantir* un noyau tps partagé rapide et stable (pas de trolls là non plus , simplement qu il faut bien avoué que les entreprises préfèrent un *BSD à un Linux , car ils sont soit disant "plus stable" .)
(Ps : si vous moinsé merci de me dire pkoi , ca m evitera de réessayer de demander des explication sur tel ou tel devellopement )
[^] # Re: Sortie de RTAI 24.1.12
Posté par Jimmy . Évalué à 3.
Avec un OS open-source, tu peux t'assurer toi-même de l'agorithme d'ordonnancement utilisé, eventuellement le patcher ...
Je en pense pas que le terme "garantie" s'applique ici en termes juridiques : je te vois mal coller un procès à un éditeur d'OS parce que ton air-bag ne s'est pas déclenché à temps ...
C'est plus une caractéristique du produit, tout dépend de ce que tu en fais. Par exemple, un bête printf() ajouté pour débugger une fonction va complètement bousiller ton beau séquencement de tâches périodique à 10ms, OS temps réel ou pas.
JiM
[^] # Re: Sortie de RTAI 24.1.12
Posté par LeMagicien Garcimore . Évalué à 1.
Je ne suis pas un specialiste du domaine, mais je pense que justement, un éditeur qui te vend un OS qui a des prétentions temps réel peut être attaqué en justice si son système ne repond pas aux exigence. En faisant ton choix, tu as regardé les caractéristiques de l'OS (temps de lantence...) en fonction de ton application.
Quand t'achète une voiture, si on te dit qu'ell à 5 vitesses et qu'en fait, elle n'en n'a que 4, tu peux légitimement gueuler :)
[^] # Re: Sortie de RTAI 24.1.12
Posté par Jimmy . Évalué à 2.
Celà dit, si les performances annoncées ne sont pas au rendez-vous tu vas vite t'en rendre compte, à condition que tes jeux de tests soient bien faits, evidemment. Mais il ne faut pas attendre un problème grave pour ca !
Il y a quand même un minimum de validation et de tests qualité à faire avant de lâcher une application temps réel critique dans la nature. Les éditeurs le savent, et font attention à ce qu'ils annoncent (on n'est pas dans le domaine de l'OS bureautique avec écrans bleus ... d'aillleurs y'a pas toujours d'écran, juste un bon vieux terminal serie pour debugger)
Donc, entre bencher un OS proprio, et bencher un OS libre dans les mêmes conditions que l'application à développer, je ne vois pas la différence. Sauf que si les resultats ne te plaisent pas, tu peux aller regarder comment ca marche dans le cas de l'OS libre. Pour le proprio, tu attends la prochaine release ...
Un autre argument est le nombre d'architectures (processeurs) supportés. Un éditeur facturera très cher le portage de son OS sur un nouveau processeur, tandis qu'une bande d'enthousiastes peut porter linux et les extensions temps-réel sur n'importe quel CPU. Par exemple, le portage de µClinux sur le processeur reconfigurable MicroBlaze est en cours dans une université australienne. http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/(...)
Je pense que la possibilité de trainer en justice un fournisseur n'a pas la même valeur que le fait de produire un système maitrisé dans sa totalité.
JiM
[^] # Re: Sortie de RTAI 24.1.12
Posté par snurpsss . Évalué à 1.
Il me viens une seconde question , un peu plus personnelle : je travaille dans le milieu boursier (dans une salle des marchés en fait ) et on utilise beaucoup le terme "temps reel" mais pour des applis windows , donc forcement qui ne sont pas en temps réelles .
Y a t il des modifications permettant de baisser le tps de latence sous les OS de crosoft , a la facon d'un patch kernel ? (je m attend pas a ce qu on me donne un patch , mais peut etre un noyau modifié pour windows . (ps il s agit d'une info en rapport avec le tps reel , pas reellement avec linux , inutile de moinser ;) )
Je demande ca car a par essayer de faire fonctionné sous wine ces fameuses appli dites "tps reelles" , j ai pas trouvé grd chose pour améliorer la reactivité des produits ( quelques soucis avec GL T??? ;) )
Si d autres personnes sont aussi confrontés a ce genre de soft (sois disant tps réel , mais sur des os loin de l etre) ...
[^] # Re: Sortie de RTAI 24.1.12
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Sortie de RTAI 24.1.12
Posté par PachaFonk . Évalué à 1.
[^] # Re: Sortie de RTAI 24.1.12
Posté par Nitchevo (site web personnel) . Évalué à 5.
Ainsi si un système temps réel devait ne pas répondre dans les temps prévus il serait impossible, sans violer la GPL de chercher des poux à Linus Torvalds, ou autre développeur du noyeau.
Cependant ce que je comprends de la GPL m'incite à préciser que rien n'interdit à une entreprise de fournir une garantie sur un soft qu'elle distribue, si elle l'estime possible, en tant que service associé au logiciel distribué(et même de demander à ce titre une rémunération). Mais cette garantie n'engagera que cette entreprise, au titre d'un contrat séparé, et non l'ensemble de la communauté au titre de la GPL.
[^] # Re: Sortie de RTAI 24.1.12
Posté par PachaFonk . Évalué à 1.
- linux gere des priorite variables pour que tous le monde soit servi
- un ordonnanceur temps reel ne gere que des priorites statique ... beaucoup plus simple.
Il y a une tres bonne explication a tous ca dans l'article de P.Ficheux :
www.enseirb.fr/~kadionik/embedded/ linux_realtime/linux_realtime.pdf
[^] # Re: Sortie de RTAI 24.1.12
Posté par PachaFonk . Évalué à 2.
http://www.enseirb.fr/~kadionik/embedded/linux_realtime/linux_realt(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.