[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [HS] Temps reel [Re: horloge a la bourre]



On Fri, Nov 15, 2002 at 01:27:50PM +0100, Georges Mariano wrote:
> OK, alors qu'est ce qui _est_ temps-réel ?

Vaste question :-)

Un système temps-réel "dur" (Hard real time) est un système
qui doit garantir un temps de réponse. S'il faut donner une
commande à ton ABS toutes les 50ms, il faut garantir que la
commande soit là. En général, ces systèmes sont nécessaires
pour tout ce qui bouge.

Le temps-réel "mou" (Soft real time) suit la même idée, mais
rater une réponse n'est pas fatal (Suivant les systèmes,
"rater" ne veut pas dire la même chose: pour certains, on
peut se permettre de "sauter" une sortie, pour d'autres on
peut se permettre d'arriver en retard).

Exemple du premier type: Tu décodes du MPEG que tu affiches
sur un écran. Idéalement, tu veux donner 25 trames par
secondes à l'écran. Si tu rates une trame, il est acceptable
de la sauter (et de répeter la dernière trame). Dans ce cas,
arriver en retard ne sert à rien: l'écran ne t'attend pas,
donc passé la limite de temps, on peut aussi bien laisser
tomber le décodage qu'on était en train de faire.

Exemple du second type: Un système de détection incendie
doit faire sonner les sirènes dans les 5s après qu'un
détecteur a detecté un feu. C'est la norme qui le dit. Mais
si tu le fais après 6s, le système marche quane même, et est
quand même utile (tu as une seconde de moins pour paniquer).
(Bon, et tu rates la certification de ton matériel, mais
c'est une autre histoire).

Il y a bien entendu des combinaisons entre tout ça: des
systèmes où certaines choses sont temps réel "dur" mais
d'autres non. D'où l'interêt de RTLinux ou RTAI: on fait le
temps-réel dur correctement (en dehors de Linux), et on
utilise Linux pour le reste (stocker des choses sur disque,
parler au réseau etc).

De façon génerale, les OS "normaux" (Linux, Windows etc) ne
sont pas temps-réel "dur"; on peut les utiliser pour du
temps-réel mou si on fait attention à avoir une charge
processeur connue et deterministe (Et même comme ça, c'est
pas idéal: quand tu fais un read() sur un fichier, tu ne
sais pas combien de temps ça va prendre, et il n'y a pas de
façon simple de dire "fait un read, mais laisse tomber si ça
prend plus de 500ms". On peut le faire en fork-ant avant de
faire le read, avec le deuxième process qui attend 500ms
puis interrompt le processus qui fait le read... c'est un
peu bordélique et pas efficace.) . Pour faire du temps-réel
dur, il faut utiliser d'autres noyaux tels que VxWorks (sans
doute le plus connu), eCos, RTLinux, Nucleus... En général,
ces OS ont un paramètre supplémentaire à leurs appels
systèmes: read( fd, buffer, size, timeout )...

Voilà voilà. J'espère avoir été raisonnablement clair :-)

/Y



Reply to: