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

Patrice Kadionik kadionik at enseirb.fr
Mer 17 Déc 15:52:06 CET 2008


Patrice a écrit :
> J'ai plutôt l'impression que tu n'es pas impartial vue la teneur
> garantie en passion dans tes propos :) Je te taquine mais je reste
>   
Je suis impartial justement. j'aime que les choses soient précises, 
c'est tout...
> dans l'optique que matraquer à tout vas dans la doc "temps réel mou"
> peut prêter à une image un peu néfaste du travail effectué.
>   
Pourquoi, dire la vérité te gêne ?
L'embarqué demande rigueur et honnêté.
J'ai plus l'impression que tu as peur de vexer un mainteneur assez 
susceptible mais qui ne conteste pas le côté soft real time du patch...


> Comme je te le disais, si le temps réel est "mou" par nature dans
> l'informatique, il n'est pas "faux" de parler de temps réel sans
> spécifier à chaque fois "mou". Par contre, introduire en expliquant
> que le temps réel qui sera utilisable est "mou" dans l'intro est une
> bonne optique.
>
> Bref, je reprendrai cette conversation plus tard, je suis noyé sous le
> boulot moi
>
>   
Arg ! Le "moi" est en trop !!!
Sache que j'ai passé 2 h à corriger ton document.
Maintenant, fais comme tu veux... j'aurai simplement l'impression 
d'avoir perdu 2 h...

pk
> Le 17 décembre 2008 12:54, Patrice Kadionik <kadionik at enseirb.fr> a écrit :
>   
>> 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 +
>> +----------------------------------------------------------------------+
>>
>>
>> _______________________________________________
>> 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