[fedora-fr-doc] Doc Mise en oeuvre du patch PREEMPT-RT

Patrice Kadionik kadionik at enseirb.fr
Mer 17 Déc 12:54:55 CET 2008


Re,

Ca va devenir une querelle de spécialistes...
Patrice a écrit :
> Le souci c'est que Steven a l'air de se contrer à cette optique car le
> TR proposé par le patch ne correspond pas franchement à du temps réel
> mou. Il parle d'ailleur du fait que de dire "soft RT" est limite
> insultant (http://en.wikipedia.org/wiki/Pet_peeve si vous lisez sa
> réponse)
>
> Le patch RT proposé par Ingo et maintenant Steven ne correspond pas à
> du temps réel mou proposé de base dans les options de compilation de
> kernel. Le terme PREEMPT-RT est certes plus adéquat (car on ne
> spécifie pas mou ou dur :) ).
>   
oui, le patch PREEMPT-RT est meilleur en moyenne en temps de latence que 
les patchs trditionnels kpreempt ou low latency dans le noyau.
Jusqu'à preuve du contraire, preempt-rt est du même acabit : on n'est 
pas sûr d'avoir dans 100 % des cas un temps de latence borné et garanti. 
Pourquoi il existe des systèmes à conoyaux comme RTLinux, RTAI et 
maintenant Xenomai.

maintenant, on va tomber sur un problème d'égo. Ce n'est pas parce qu'on 
maintient un projet qu'on ne raconte pas de bêtises...
Si l'on veut être honnête intellectuellement, on NE DOIT PAS parler 
aujourd'hui de Temps Réel tout court à cause de cette  c... de Temps 
Réel mou. On doit préciser.
preempt-rt reste TR mou même si c'est l'un des meilleurs patchs.
Je pense qu'il faut laisser le terme "mou". C'est la réalité...

> Mais si Steven exprime justement ce souci de terme, je pense qu'il est
> bon d'en parler... Quand je parle de mono kernel, je veux dire que le
> temps réel dur comme tu le spécifie est implémenté en général avec
> deux instance de noyau, chose que le patch ne propose pas.
>
> Mon souci c'est que Steven a l'air de bonne fois et comme en plus
> c'est lui qui continue le développement de ce patch (patch énorme
> d'ailleurs puisqu'il impacte un énormément de sources dans le noyau),
> j'ai tendance à vouloir écouter son opinion aussi...
>
> Il a bossé dans l'électronique et connait aussi le sujet, il exprime
> justement ce que tu dis en terme de "life or death operating systems".
> Si le terme "mou" est limite insultant pour eux et que en plus il n'a
> pas vraiment de sens dans l'informatique (car comme tu le dis si bien,
> en informatique on ne parle finalement que de temps réel mou... à
> moins d'avoir deux machine et deux kernel prévu pour cela et dans ce
> cas on tape dans une solution matérielle) alors pourquoi devrait-on
> spécifier "mou" ?
>
> Surtout que ce terme peut prêter à confusion, on m'a envoyé un mail me
> demandant pourquoi utiliser un truc lent peut améliorer le système...
> je pense que "noter" ou "faire remarquer" que le temps réel proposé
> par le patch est du temps réel mou est plus adéquat que d'insister en
> précisant à chaque fois le terme "temps réel mou".
>   
simplement pour ne pas tromper les gens car dans leur inconscient :
TEMPS REEL=TEMPS DUR  ce qui est faut ici....
> Je suis de ton avis en ce qui concerne le principe, mais de l'avis de
> Steven en ce qui concerne l'insistance du terme. Je pense que le plus
> important est de parler de temps réel, et de notifier en intro ou en
> conclusion que dans l'info on ne parle que rarement de temps réel
> dur...
>   
non. Le temps réel est dans la majeure partie des cas du temps réel dur 
dans la "vraie vie".
Le temps réel mou est récent et n'assure qu'une certaine QoS dont on a 
besoin dans le multimédia...

Si tu ne veux pas choquer, tu mets dans la doc en intro que preempt-rt 
est TR mou ainsi que dans la conclusion... Tu peux mettre Temps Réel 
tout court dans le reste.
Il faut être précis, rigoureurx, honnête et impartial même si ça peut 
heurter qq égos... On a le droit d'être critique et impartial non ?

Patrice
> Le 17 décembre 2008 11:24, Patrice Kadionik <kadionik at enseirb.fr> a écrit :
>   
>> Salut.
>>
>> Le temps Réel mou est une notion inventé par les informaticiens il y a
>> qq années.
>> Pour l'électronicien, il n'existe que le Temps Reel dur ou Temps Réel.
>>
>> J'ai donné la différence dans :
>> http://doc.fedora-fr.org/wiki/Fedora_Core_et_le_Temps_R%C3%A9el
>>
>> Patrice a écrit :
>>     
>>> Bonjour à tous,
>>> J'ai un petit soucis en ce qui concerne le terme de "temps réel mou"
>>> et "temps réel dur"... Je vais vous expliquer le pourquoi.
>>>
>>> Comme je commence à packager un kernel RT, je me suis dis que le mieux
>>> serait de contacter Ingo Molnar... chose que j'ai fait.
>>>
>>> Ce dernier m'a réorienté vers le nouveau mainteneur de ce patch qui
>>> est Steven Rostedt. J'ai donc put échangé avec lui et lorsque je
>>> parlais de soft real time (temps réel mou), Steven a répondu en ces
>>> termes:
>>>
>>> "I will comment on the 'soft real time'.
>>> This is a pet peeve[1] of mine. The term soft real time means that the
>>> system can miss a deadline and still be OK. When someone is using the -rt
>>> patch, and they miss their dead line, then that is a bug. It is not OK.
>>> Thus, the -rt patch is really meant to be 'hard real time'. The problem is
>>> that the term 'hard real time' is associated with life or death operating
>>> systems like airplane engine controls (which I have worked on).
>>>
>>> The difference between a RTOS that is on a airplane and the linux rt
>>> kernel, is that one has been tested much harder. The goal is still the
>>> same (guaranteed latency), but the amount of effort to prove it can make
>>> the deadline is under stricter guidelines in the airplane engine OS than it
>>> is in a factory making cars.
>>>
>>> What I'm trying to state, is that there is no such thing as 'hard real
>>> time' or 'soft real time'. There is only 'real time' with different levels
>>> of quality assurance ;-)"
>>>
>>> Si je comprend bien, le patch RT n'est pas vraiment un patch pour
>>> faire du temps réel dur ni mou... c'est bien du temps réel... avec un
>>> niveau acceptable de qualité.
>>>
>>> En tout cas il a l'air contre l'idée d'appeler (ou du moins de
>>> préciser) que c'est du temps réel "MOU". C'est d'ailleurs un point de
>>> vue que je partage puisque le principe du patch est largement au delà
>>> d'un niveau de preemption mou... on est proche du temps réel dur avec
>>> la contrainte de mono kernel... si vous me suivez...
>>>
>>>
>>>       
>> Dans l'embarqué et le TR, c'est soit blanc soit noir... Tu est TR dur ou
>> pas...
>> L'ambiguité tient au faut qu'on met sous TR le TR dur et le TR mou des
>> informaticiens.
>> PREEMPT-RT est TR mou...
>> "on est proche du temps réel dur avec la contrainte de mono kernel" ne
>> veut rien dire. Tu l'es ou pas. Es-tu sûr que dans 100 % des cas le
>> temps de latence est borné avec PREEMPT-RT ? Non.
>> Donc c'est du TR mou...
>> J'ai déjà eu cette conversation à Solutions Linux 2008. Linux avec tous
>> les patchs d'amélioration de la préemption ne le rendront pas TR dur...
>> L'arnaque est de parler de Temps Réel tout court aujourd'hui. IL FAUT
>> PRECISER DUR OU NON DUR SOIT MOU MAINTENANT ! C'est tromper les gens
>> sinon ! Je sais que les informaticiens parlent de Temps Réel tout court
>> car ils ne savent pas trop ce que ça veut dire et induit.
>>
>> Je sais que l'on a raison de dire PREEMPT-RT est TR mou. Je ne suis pas
>> le seul à le dire aussi. P. Ficheux aussi.
>>
>> ++
>> Patrice
>>     
>>> Bref, selon les termes de Steven, je devrai expliquer cela dans la
>>> doc... vous pensez pas ?
>>>
>>>
>>> Le 16 décembre 2008 12:00, Patrice <metal3d at gmail.com> a écrit :
>>>
>>>       
>>>> En relisant mon article je me suis rendu compte que nous pouvions
>>>> faire un peu mieux...
>>>> D'abord j'ai ajouté "l'astuce" pour la phase de compilation de noyau
>>>> qui consiste à ajouter l'option "-j 3" pour les processeur dual-core
>>>> ou multi-proc
>>>>
>>>> Ensuite, ce que je n'ai pas fait, c'est d'ajouter une méthode plus
>>>> "propre" au niveau de grub qui consiste non pas à éditer le fichier à
>>>> la main mais d'utiliser soit grubby soit new-kernel-pkg (je suis en
>>>> cours de tests puisque je package depuis peu un noyau RT pour créer
>>>> Fedora Studio).
>>>>
>>>> Je me suis mis en relation avec Ingo Molnar qui m'a appris que ce
>>>> n'est plus lui qui gère ces travaux mais Steven-Rostedt depuis
>>>> quelques temps. Je pourrais certainement avoir quelques infos à
>>>> ajouter dans l'article.
>>>>
>>>>
>>>> L'aricle a l'air bien en place, on l'ajoute dans la doc (rublrique) ?
>>>>
>>>> --
>>>> http://www.metal3d.org
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>> --
>> Patrice Kadionik. F6KQH / F4CUQ
>> -----------
>>
>> +----------------------------------------------------------------------+
>> +"Tout doit etre aussi simple que possible, pas seulement plus simple" +
>> +----------------------------------------------------------------------+
>> + Patrice Kadionik             http://www.enseirb.fr/~kadionik         +
>> + IMS Laboratory               http://www.ims-bordeaux.fr/             +
>> + ENSEIRB                      http://www.enseirb.fr                   +
>> + PO BOX 99                    fax   : +33 5.56.37.20.23               +
>> + 33402 TALENCE Cedex          voice : +33 5.56.84.23.47               +
>> + FRANCE                       mailto:patrice.kadionik at ims-bordeaux.fr +
>> +----------------------------------------------------------------------+
>>
>>
>> _______________________________________________
>> fedora-fr-doc mailing list
>> fedora-fr-doc at fedora-fr.org
>> http://mailing-list.fedora-fr.org/mailman/listinfo/fedora-fr-doc
>>
>>     
>
>
>
>   


-- 
Patrice Kadionik. F6KQH / F4CUQ
-----------

+----------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple" +
+----------------------------------------------------------------------+
+ Patrice Kadionik             http://www.enseirb.fr/~kadionik         +
+ IMS Laboratory               http://www.ims-bordeaux.fr/             +
+ ENSEIRB                      http://www.enseirb.fr                   +
+ PO BOX 99                    fax   : +33 5.56.37.20.23               +
+ 33402 TALENCE Cedex          voice : +33 5.56.84.23.47               +
+ FRANCE                       mailto:patrice.kadionik at ims-bordeaux.fr +
+----------------------------------------------------------------------+





Plus d'informations sur la liste de diffusion fedora-fr-doc