jeudi 10 avril
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | O'Reilly | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : La guerre du temps réel

Posté par patrick_g (page perso, ). Modéré le 13 décembre 2007.
Linux
Les deux grandes distributions commerciales, Novell et Red Hat, ont récemment annoncé la sortie d'une version dédiée spécialement au temps réel et la compétition s'annonce âpre dans ce secteur stratégique. Novell a ouvert le feu le 27 novembre avec SUSE Linux Enterprise Real Time 10 et Red Hat a immédiatement répliqué le 4 décembre avec Red Hat Enterprise MRG (Messaging, Realtime et Grid Technologies).

Cette volonté de ne pas laisser un concurrent en position de monopole sur ce secteur, même pour une durée infime, s'explique aisément. En effet de plus en plus les entreprises reposent sur l'automatisation poussée de leurs processus afin de gagner en réactivité. 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.

La prédictibilité des temps de réponse est donc un enjeu crucial et les distributeurs commerciaux de Linux sont en compétition pour couvrir ce marché au point, comme nous allons le voir, de déclencher une véritable guerre des communiqués.

> Lire la dépêche (53 commentaires, moyenne: 4,9).  

Depuis plusieurs années la branche principale du noyau Linux a intégré de nombreux patchs ayant un rapport, proche ou lointain, avec la problématique du temps réel. On peut songer aux mutex, à l'héritage de priorité ou encore la gestion dynamique des tranches de temps. De ce point de vue Linux est donc devenu une solution envisageable pour du temps réel « mou » (donc avec une certaine tolérance pour des latences de traitement).

Pour accéder au vrai temps réel il faut néanmoins intégrer beaucoup plus de patchs au noyau Linux et ces patchs, bien qu'en développement depuis longtemps, n'ont pas encore rejoints la branche principale. Le site LWN avait décrit ces modifications temps réel dans un article d'octobre dernier et avait abouti a un décompte de près de 400 patchs.
On y trouve notamment le remplacement des spinlocks par des mutex temps réel entièrement préemptibles et bénéficiant de l'héritage de priorité. Il existe aussi un patch permettant de gérer les interruptions dans des threads séparés et un autre qui modifie la gestion des pages mémoires pour éliminer les verrous.
Tout ce travail est donc disponible pour ceux qui désirent appliquer ces patchs au noyau traditionnel (c'est ce que fait la branche -rt) et cette série de patchs forme la base de ce qui se trouve dans les deux nouvelles offres de Novell et de Red Hat.

L'aspect technique des noyaux temps réel est toutefois un peu occulté dans les communiqués officiels rédigés par les département marketing au profit de phrases telles que « increase revenue opportunities » ou « grow their own top-line revenues » ou encore « customers gain time advantage over competitors to make more money or avoid financial losses ».
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.

Du coté Novell la réponse a été prompte :
Note à Red Hat: C'est de l'open source vous vous souvenez ? Novell propose un Linux testé est 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.

LWN s'est penché sur cette controverse et son verdict est assez nuancé : "En fait une bonne partie de ce travail, incluant le travail crucial de bas niveau sur la préemption qui a permis l'avancement du projet temps réel, a été effectué par Red Hat. Mais d'autres composants viennent de compagnies comme MontaVista, Linutronix, TimeSys et, oui, Novell (ainsi que d'autres bien entendu). Pour ces deux compagnies le fait de se disputer au sujet du crédit en tant qu'auteur du code est un peu stupide. Les deux sont des contributeurs significatifs du noyau (et au-delà)".

L'article de LWN indique également qu'au niveau des développeurs il n'y a aucun signe d'animosité et que le travail en commun sur la LKML ou les listes spécialisées se déroule bien. La tension semble se concentrer chez les gestionnaires et des managers des deux firmes qui perçoivent l'importance des enjeux financiers. A titre d'exemple cet article indique que le coût d'une licence Novell SLERT est de 2500 dollars par serveur (en plus des 799 dollars la licence SLES classique). Du coté Red Hat ce sera sans doute comparable.

Dans le monde du logiciel libre il est difficile d'obtenir un avantage comparatif sur ses concurrents puisque ces derniers peuvent réutiliser votre code. La compétition doit donc se déplacer sur d'autres secteurs comme la capacité d'expertise interne ou le service, le support, le développement d'adaptations spécifiques...etc.
Cette nouvelle donne met du temps à être intégrée par les managers traditionnels qui raisonnent encore en terme d'attribution de paternité et de communiqués triomphants. En 2005 on avait déjà assisté à une répétition de la situation d'aujourd'hui (à l'époque c'était Montavista contre Red Hat) et nous devons nous attendre à en voir encore à l'avenir.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

trem-RT :)

Posté par bubar () le 13/12/2007 à 10:13. (lien). Évalué à 8.

Les utilisateurs Mandriva, comme moi, qui souhaiteraient essayer un noyau temps-réel dur (solution patch de l' équipe de Mr Molnar) peuvent le faire simplement en installant le(s) rpm(s) correspondant :

kernel-rt (et les sources si besoin...).
Ce kernel a rejoint le dépôt Contrib pour la 2008.
urpmi kernel-rt-latest kernel-rt-source-latest
(il y a aussi une version kernel-rt-SMP)

Et les utilisateurs enchainé au blob de nvidia seront "heureux" d' apprendre que le driver nvidia fourni par le PLF est patché pour supporté un noyau temps-réel dur. (le driver nvidia n' étant pas copain, pour le moment, avec un noyau temps-réel)

ps : n' oubliez pas de customiser le fichier limits.conf afin d' y renseigner correctement les nouveaux ""droits"" pour votre utilisateur.

Merci pour cette dépêche, passionante.

Adeos, RTAI, Xenomai

Posté par David (page perso, ) le 13/12/2007 à 11:07. (lien). Évalué à 7.

J'aimerais souligné l'existance de RTAI et Xenomai, utilisant tous les 2 Adeos, dans ce monde du "temps-réel dur" et libre.

J'ai eu l'occasion d'utiliser Adeos et j'ai adoré le concept.

A+

C'est bien mignon tout ça

Posté par GeneralZod () le 13/12/2007 à 11:16. (lien). Évalué à 6.

... mais c'est de la gueguerre marketing.
Même si les principaux architectes de kernel-rt sont certes Ingo Molnar (RedHat) et Thomas Gleixner (Linutronix - auteurs des High Resolution Timer), kernel-rt reste un effort collectif.
Novell a mis deux développeurs sur kernel-rt : Gregory Haskins & Adam Bellay et ils sont loin d'être passifs. C'est compréhensible que RedHat n'apprécie pas de s'être fait grillé la politesse, ils ont démarré kernel-rt, et ont investi 5/6 développeurs sur le projet mais c'est du logiciel libre, faut jouer le jeu.

Enfin, malgré que PREEMPT_RT a encore pas mal de boulot pour arriver à concurrencer les RTOS classiques, il est relativement mature. Si on est pas trop exigeant au niveau des latences, on peut arriver à du déterminisme strict.

Pour ceux qui veulent des vrais informations sur l'état du Temps-Réel dans le noyau Linux:
http://rt.wiki.kernel.org/index.php/Main_Page
http://www.osadl.org/
http://linuxdevices.com/articles/AT4991083271.html
http://lwn.net/Articles/252716/
http://lwn.net/Articles/248929/
https://ols2006.108.redhat.com/

Il serait intéressant

Posté par Francois Revol (page perso, ) le 13/12/2007 à 11:25. (lien). Évalué à 7.

d'étudier l'impact de l'ouverture du code de QNX...
http://www.osnews.com/story.php/18596/QNX-Opens-Neutrino-Sou(...)

WindRiver si met aussi

Posté par Jetto () le 13/12/2007 à 13:57. (lien). Évalué à 3.

http://www.windriver.com/fr/press/pr.html?ID=4363

Normalement Windriver devrait sortir une offre autour de RTLinux...
A suivre

Re:

Posté par IsNotGood () le 13/12/2007 à 13:58. (lien). Évalué à 1.

> Red Hat a immédiatement répliqué le 4 décembre
> Cette volonté de ne pas laisser un concurrent en position de monopole sur ce secteur, même pour une durée infime

Je crois qu'on est dans le délire ici.
Peut-être Red Hat a bougé son calendrier de 1 ou 2 semaines. Mais c'est tout.

Red Hat parle depuis longtemps d'une version temps réel pour serveur. La solution devait être basée sur RHEL 6. Il y a quelques mois (oui, des mois et pas des jours) Red Hat a dit que la version temps réel sera basée sur RHEL 5.

Dans le domaine des serveurs, "être le premier" n'est pas un critère très important. Les gros clients sont prêts à attendre pour avoir la garantie d'une solution qui marche.

Pour rappel, Novell a aussi été le premier à sortir Xen dans une distribution entreprise. Red Hat a fait son offre de virtualisation des mois après Novell.
Ben ça n'empêche pas Red Hat de se porter comme un charme et de faire un carton dans la virtualisation.

Attention

Posté par farib () le 13/12/2007 à 19:40. (lien). Évalué à 4.

Le patch RT, c'est bien, mais attention à ne pas appliquer le patch RTT, qui, lui, a des performances plutot douteuses.

Revenir en haut de page

Run by Team LinuxFr

Cette page a été générée par Templeet en 0.1786s (dont 0.0199 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.