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

Patrice Kadionik kadionik at enseirb.fr
Mer 17 Déc 11:24:38 CET 2008


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 +
+----------------------------------------------------------------------+





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