Linux, la "guerre" du noyau RT

Hanz0 · Le 18/12/2007, à 11:59

Noyau RT pour Real Time ou temps réel.
C'est d'abord Novell qui à inauguré les hostilités le 27 Novembre, suivi de près à la corde le 4 Décembre par Red Hat.
Le développement de ce type de noyau fait en effet l'objet d'un marché très porteur dans les milieux financiers.
En effet, fini le temps de téléphoner à son banquier:"Prenez-en 1000 de cette action.".
Aujourdâ€™hui beaucoup de taches sont automatisées et on parle en milliards de dollars avec des temps d'action très réduit.

On se rappelle, lors du sommet Linux 2007, le témoignage du représentant du Crédit Suisse qui indiquait qu'un noyau patché pour le temps réel aidait à maintenir les profits lors d'une transaction financière.

Même si nous sommes dans le monde du logiciel libre, certaines remarques sont tout de même bien piquantes, d'un cà´té comme de l'autre.

Cette compétition marketing a été particulièrement farouche et un des dirigeants de Red Hat est allé jusqu'à remettre en cause les contributions de Novell dans le domaine du temps réel.
Selon Scott Crenshaw le noyau Novell temps réel n'est pas stable et il ne serait que de la qualité d'une bêta. De plus les patchs RT ont été écrits à 80% par des développeurs Red Hat ce qui remettrait en cause le niveau de compétence de Novell sur ce sujet. Scott Crenshaw a ajouté sarcastiquement:
"Nous souhaitons la bienvenue à Novell dans la communauté temps réel. Nous espérons qu'elle fera des contributions à l'avenir."

Réponse de Novell:

Note à Red Hat: C'est de l'open source vous vous souvenez ? Novell propose un Linux testé et renforcé pour les entreprises avec des capacités temps réel. Ce n'est pas parce que Red Hat est une fois de plus en retard sur le marché (voir le desktop Linux pour les entreprises, la virtualisation avec Xen...etc) que cela signifie que notre noyau contient du code de qualité bêta (...) Ce n'est pas plus du code Red Hat que les millions de lignes de code apportées par Novell (...) C'est ça le modèle Open Source.

On va les laisser se chamailler gentiment car de toutes manières Microsoft ne propose aucune alternative au noyau RT

Encore une longueur d'avance pour le manchot.

Source: http://linuxfr.org/2007/12/13/23447.html
Novell Suse RT: http://www.novell.com/news/press/novell-ships-suse-linux-enterprise-real-time-10
Red Hat RT: http://www.redhat.com/about/news/prarchive/2007/mrg.html

dekans · Le 18/12/2007, à 17:34

j'ai entendu dire que le noyau de vista est préemptif.
Si c'est le cas, Microsoft est pas en retard, voire même un peu en avance

anaxagold · Le 18/12/2007, à 17:43

Tous les noyaux d'OS sont préemptifs (une tà¢che peut en interrompre une autre) depuis très longtemps.

Le plus apporté par un noyau RT est le fait que (normalement) il existe un majorant aux temps de réponse aux événements (interruptions en général). Les "vrais" noyaux RT sont rares. Ils sont inutiles dans le cadre d'un simple poste de travail (les problèmes de streaming multimédia sont traités à part).

La méthode classique consiste à développer un micro-noyau qui capture les événements puis les traite (au plus vite) ou les transmet à un OS considéré comme une simple tà¢che non-RT (qui les traitera quand il aura le temps). C'est ce que font, en général, les patches RT.

Dernière modification par anaxagold (Le 18/12/2007, à 17:45)

lucmars · Le 18/12/2007, à 22:12

Il me semble aussi que le noyau RT importe pour la téléphonie mobile (mais peut-être pour les mêmes raisons évoquées plus haut).
Je me demande si le noyau Monta Vista est un Linux patché ou un fork ?

anaxagold · Le 19/12/2007, à 11:52

Les noyaux temps réels sont très importants pour toutes les applications de contrà´le industriel.

- contrà´le des procédés
- stockeurs vidéo (pour la vidéosurveillance par exemple)
- ... par exemple

Dans ce type d'application Linux fait merveille (stabilité et facilité de tailler un noyau sur-mesure)

LeJediGris · Le 21/12/2007, à 17:45

Oui faudrait un cours sur ce qu'est réellement le temps-réèl.

Etre préemptif ne veut pas dire garantir l'execution dans un laps de temps donné. Un traitement "normal" s'il s'execute dans le temps imparti par le système global peut être considéré comme "temps-réel". Etre préemptif veut simplement dire qu'une priorisation existe entre les tà¢ches et un mécanisme permet d'interrompre la tà¢che courante de faible priorité par une autre de plus forte priorité. C'est un complément au Round-Robin et au batch. Par contre la préemption avec changement de contexte peut-être d'une lenteur affligeante...sur certains OS.

Dans les applications industrielles "critiques" là ou le RT signifie Âµs (micro-secondes) les noyaux d'OS préemptif légers ont du mal a faire leur entrée. Il existe pour cela (encore pour un peu de temps) des séquenceurs de tà¢ches ou des systèmes très simples spécifiques.

Dire que Windows est préemptif me fait rire, même si c'est vrai. Essayez d'interrompre rapidement une tache d'impression ou une écriture massive sur DD ou DVD...

Par contre c'est vrai que l'arrivée des multi-coeurs et l'utilisation de noyaux préemptifs multithreads (capables EFFECTIVEMENT de lancer de façon indépendante plusieurs threads et leur contexte sur des processeurs distincts, avec affinité donc) ouvre un marché non négligeable pour des OS plus "lourds" dans ces secteurs industriels dits "contraints" (en temps d'exec, en fiabilité/sécurité)

A+

sonal · Le 22/12/2007, à 12:30

Hanz0 a écrit :

On va les laisser se chamailler gentiment car de toutes manières Microsoft ne propose aucune alternative au noyau RT

Je suis peut-être completement à la rue ou hors sujet, mais ca fait pas un bout de temps qu'on a une faible latence sous windows (par exemple avec Cubase ou des outils industriels de simulation)

dekans · Le 22/12/2007, à 13:05

LeJediGris a écrit :

Dire que Windows est préemptif me fait rire, même si c'est vrai. Essayez d'interrompre rapidement une tache d'impression ou une écriture massive sur DD ou DVD...

Une impression ca n'est pas ce qu'il y a de plus prioritaire comme tâche, c'est pour ca que ca prend toujours autant de temps, voire même plus parce que d'autres services l'interrompent sans cesse.

Et tous les OS ne sont évidemment pas temps réel, j'ai gutsy avec un noyau patché temps réel (RTAI)
Du coup même avec fluxbox c'est lent parfois !
Parce que l'interface graphique n'est pas la priorité.

LeJediGris · Le 22/12/2007, à 21:53

Ben justement, un VRAI noyau preemptif devrait "virer" le programme lent en background (impression par exemple) pour s'executer !!

A+

Astidiel · Le 22/12/2007, à 22:27

Petite précision sur le temps réel (certainement pas un cours, ce serait beaucoup trop long... et j'ai laissé mes cours dans mon studio pendant mes vacances...)

La notion important à considérer lorsqu'on parle de temps réel est le déterminisme. C'est à dire la possibilité d'assurer un temps d'exécution maximale à chaque tà¢che.

C'est une notion très complexe à appréhender correctement, cela implique beaucoup de chose au niveau du système et notamment au niveau de l'ordonnancement ( la manière dont un système exécute les tà¢ches).

En général, les systèmes temps réels sont classés en deux catégorie, selon l'importance d'obtenir un bon résultat ou l'importance de parvenir à un résultat dans les temps :

Temps réels stricts : l'importance absolue est le respect des contraintes temporelles, la fiabilité du résultat est d'importance moindre (ce qui ne veut pas dire sans importance...). Ces systèmes sont utilisés lorsque le dépassement d'un temps limite peut avoir des conséquences critiques (ABS, téléguidage de missile, contrà´le d'appareil aérien...)

Temps réels souples : l'importance est d'obtenir un résultat fiable, la durée d'exécution de la tà¢che devant respecté un temps moyen. La majorité des systèmes temps réels font partit de cette catégorie (contrà´leur de four à micro-onde, de machine à café et machines en tout genre, routage de réseaux, de flux d'informations...)

Dans le cas de ce sujet, on parle de temps réels souples (un noyau linux patché ne sera jamais temps réel strict).

LeJediGris · Le 22/12/2007, à 23:49

Euhhh non pour un ABS la fiabilité est aussi importante que le temps de réponse, mais ta distinction est bonne... on attends pas forcement "immédiatement" le résultat d'une" commande" sur les navigations embarquées, par contre un ABS ou un ESP...faut que ca marche de façon fiable en temps et en heure !!

A+

dekans · Le 23/12/2007, à 01:00

LeJediGris a écrit :

Ben justement, un VRAI noyau preemptif devrait "virer" le programme lent en background (impression par exemple) pour s'executer !!
A+

D'oà¹ la lenteur de l'impression et pas du système !

nknico · Le 23/12/2007, à 01:20

Windows CE est en temps réel non ??

LeJediGris · Le 23/12/2007, à 01:21

Oui justement, mais j'ai l'impression (sans jeu de mots) qu'il n'y a pas beaucoup de personnes qui ont fait des impressions sur w$...

Si on lance une appli genre word en parallèle d'une impression ou d'une copie disque, sans multicore ben essayez !!

A+

LeJediGris · Le 23/12/2007, à 01:22

Windows CE est un windows dégraissé pour être portable sur téléphones et PDAs.. ca n'a rien a voir avec le TR.

nknico · Le 23/12/2007, à 01:31

Ha il me semblait....vu qu'il travaillent avec le secteur automobile. Donc j'espère que tout les elements critiques sont assurés par autre chose.

LeJediGris · Le 23/12/2007, à 01:46

Oui je te rassure....en fait c'est cantonné au multimédia et aux applis non critiques. Et encore sur beaucoup de systèmes de nav+multimédia dans les voitures c'est Linux qui est intégré (exmple:PSA).

A+

Karl_le_rouge · Le 26/12/2007, à 10:51

WinCE n'est pas un windows dégraissé mais un noyau complétement différent, tu dois confondre avec XP Embedded.
Microsoft prétends que WinCE 6.0 est temps-réel dur, c'est pas totalement faux, mais personnellement, je refuse de l'employer dans des tà¢ches "safety critical". C'est bourré de bogues, le déterminisme n'est pas assuré et c'est loin d'être utilisable en industrie.

lucmars · Le 28/12/2007, à 19:31

LeJediGris a écrit :

Euhhh non pour un ABS la fiabilité est aussi importante que le temps de réponse, mais ta distinction est bonne... on attends pas forcement "immédiatement" le résultat d'une" commande" sur les navigations embarquées, par contre un ABS ou un ESP...faut que ca marche de façon fiable en temps et en heure !!
A+

Je pense que tu confonds deux choses : d'une part la cybernétique, qui est en ce cas en temps réél strict, et d'autre part les effectuateurs (plaquette de frein, machoires, pression hydraulique, niveau, capteur) qui doivent être et maintenus fiables.

Exemple: ta boite noir ABS fait un calcul correct en temps réel, mais t'as pas changé les plaquettes de frein ni révisé les machoires => va te faire voir dans un platane.
Exemple plus simple encore : tes capteurs sont défectueux ; ta boite noire ABS fait quoi dans ces conditions ? Elle te commande un cercueil chez Leclerc ?

Dernière modification par lucmars (Le 28/12/2007, à 19:32)

sonal · Le 28/12/2007, à 20:10

lucmars a écrit :

Je pense que tu confonds deux choses : d'une part la cybernétique, qui est en ce cas en temps réél strict, et d'autre part les effectuateurs (plaquette de frein, machoires, pression hydraulique, niveau, capteur) qui doivent être et maintenus fiables.

Oui. de plus, s'il est relativement aisé d'avoir une certitude d'avoir un resultat à une certaine recurrence (ces calculateurs ont une charge à peu près constante et il suffit alors de dimensionner la capacité du controleur en fonction), je ne suis pas certain que ce temps soit le plus critique dans la chaine de detection et d'action d'un ABS (acquisition des vitesses de chacune des roues, transfert et traitement, et prise en compte des actions à réaliser par les actionneurs)

LeJediGris · Le 03/01/2008, à 11:55

lucmars Le 28/12/2007, à 18:31
LeJediGris a écrit:
Euhhh non pour un ABS la fiabilité est aussi importante que le temps de réponse, mais ta distinction est bonne... on attends pas forcement "immédiatement" le résultat d'une" commande" sur les navigations embarquées, par contre un ABS ou un ESP...faut que ca marche de façon fiable en temps et en heure !!
A+
Je pense que tu confonds deux choses : d'une part la cybernétique, qui est en ce cas en temps réél strict, et d'autre part les effectuateurs (plaquette de frein, machoires, pression hydraulique, niveau, capteur) qui doivent être et maintenus fiables.
Exemple: ta boite noir ABS fait un calcul correct en temps réel, mais t'as pas changé les plaquettes de frein ni révisé les machoires => va te faire voir dans un platane.
Exemple plus simple encore : tes capteurs sont défectueux ; ta boite noire ABS fait quoi dans ces conditions ? Elle te commande un cercueil chez Leclerc ?

Bon, les gars, les ABS (encore plus les ESP) ont des modes dégradés (en partie de sauvegarde en cas de capteurs/actionneurs defectueux) qui préviennent et assurent tant que faire se peut la sécurité du conducteur. Un "effectuateur" s'appelle un actionneur, cf http://fr.wikipedia.org/wiki/Actionneur une "cybernetique" s'appelle un ensemble de pilotage ou si tu veux des lois de commandes, généralement continues assurés par un système temps-réel qui lui est par essence discret.

Les nouveaux standards de classification/qualification pour ce genre de système temps-réel sont l'IEC 61508 et bientà´t pour l'automobile l'ISO 26262. Tu verras que dans ces normes, les risques sont classifiés en fonction de leur gravité, qu'ils prennent en compte à la fois le capteur, l'actionneur mais aussi souvent l'attitude du conducteur lui-même.

Donc oui, un système temps-réel containt prend bien en compte la fiabilité et la sécurité.

La limite est et sera toujours la physique, c'est ce qu'il faut expliquer au conducteur, par exemple un ESP ne peut ramener la voiture que dans une certaine limite d'inertie, de dynamique. Le problème de ces systèmes là reste donc la BONNE INFORMATION pour le conducteur et surtout pour celui qui te vend la voiture !!

A+

Isaric · Le 01/12/2010, à 20:25

Pourquoi le noyau RT n'est pas d'office sur Ubuntu qui peut le plus peut le moins ?

Atem18 · Le 01/12/2010, à 20:37

Heliox · Le 01/12/2010, à 22:19

atem18 a écrit :

http://images.doctissimo.fr/autres/phot … 502f56.jpg

+1

Mais sa question est tout de même intéressante !

Atem18 · Le 01/12/2010, à 22:22

Heliox a écrit :

atem18 a écrit :
http://images.doctissimo.fr/autres/phot … 502f56.jpg
+1
Mais sa question est tout de même intéressante !

Ou pas.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 18/12/2007, à 11:59

Linux, la "guerre" du noyau RT

#2 Le 18/12/2007, à 17:34

Re : Linux, la "guerre" du noyau RT

#3 Le 18/12/2007, à 17:43

Re : Linux, la "guerre" du noyau RT

#4 Le 18/12/2007, à 22:12

Re : Linux, la "guerre" du noyau RT

#5 Le 19/12/2007, à 11:52

Re : Linux, la "guerre" du noyau RT

#6 Le 21/12/2007, à 17:45

Re : Linux, la "guerre" du noyau RT

#7 Le 22/12/2007, à 12:30

Re : Linux, la "guerre" du noyau RT

#8 Le 22/12/2007, à 13:05

Re : Linux, la "guerre" du noyau RT

#9 Le 22/12/2007, à 21:53

Re : Linux, la "guerre" du noyau RT

#10 Le 22/12/2007, à 22:27

Re : Linux, la "guerre" du noyau RT

#11 Le 22/12/2007, à 23:49

Re : Linux, la "guerre" du noyau RT

#12 Le 23/12/2007, à 01:00

Re : Linux, la "guerre" du noyau RT

#13 Le 23/12/2007, à 01:20

Re : Linux, la "guerre" du noyau RT

#14 Le 23/12/2007, à 01:21

Re : Linux, la "guerre" du noyau RT

#15 Le 23/12/2007, à 01:22

Re : Linux, la "guerre" du noyau RT

#16 Le 23/12/2007, à 01:31

Re : Linux, la "guerre" du noyau RT

#17 Le 23/12/2007, à 01:46

Re : Linux, la "guerre" du noyau RT

#18 Le 26/12/2007, à 10:51

Re : Linux, la "guerre" du noyau RT

#19 Le 28/12/2007, à 19:31

Re : Linux, la "guerre" du noyau RT

#20 Le 28/12/2007, à 20:10

Re : Linux, la "guerre" du noyau RT

#21 Le 03/01/2008, à 11:55

Re : Linux, la "guerre" du noyau RT

#22 Le 01/12/2010, à 20:25

Re : Linux, la "guerre" du noyau RT

#23 Le 01/12/2010, à 20:37

Re : Linux, la "guerre" du noyau RT

#24 Le 01/12/2010, à 22:19

Re : Linux, la "guerre" du noyau RT

#25 Le 01/12/2010, à 22:22

Re : Linux, la "guerre" du noyau RT

Pied de page des forums