Départ...

Ce blog a pour seul but d'exprimer toutes les idées, plus ou moins farfelues, qui me passent par la tête au sujet du temps réel. Sa réalisation s'inspire d'une discussion enflammée à la fin du cycle de conférences embarqué à Solutions Linux 2008.

Fondamentalement, j'ai tiré de cette longue discussion quelques éléments simples : tout d'abord, la notion de temps réel dur et de temps réel non-dur est un peu incomplète, l'interprétation usuelle étant que le temps réel dur est "borné". Aucun système informatique ne peut gérer des éléments en nombre non borné, et hors de toute erreur manifeste de codage (boucle infinie), un temps de réponse est toujours borné, la seule contrainte à appréhender est si le pire des cas (la borne supérieure) est acceptable, et si le cas à 99% convient.

Concrètement, Linux est-il temps réel dur ? Avec un scheduler en O(1) et des points de préemption placés dans le kernel, moyennant une expertise du code que je vais m'empresser de faire, je dirais oui. Mais pas temps réel dur à 0,1ms, ni temps réel dur à 1ms. L'ordre de grandeur ressemble plus à 10ms, ce qui peut être rédhibitoire pour certains usages (même pour contrôler un ABS on est limite). Et encore, moyennant un réglage particulier du kernel et un processeur suffisamment puissant.

Donc la bonne question est : "Mon OS peut-il garantir une échéance à x millisecondes sur mon hard dans 100% des cas ? dans 99% des cas ?". Le boulot d'ingénieur c'est de savoir conclure si oui ou non la combinaison hard/soft permet de remplir le contrat voulu.

La difficulté, non pas pour l'aspect temps réel mais beaucou plus pour l'embarqué, c'est d'accepter de surdimensionner son matériel pour atteindre le 100%. Ce surdimensionnement peut très bien être complètement inacceptable d'ailleurs (contraintes de coûts par exemple). Un hard+OS qui vous fait 1ms à 99,9% des cas et 25ms sur le 0,1% restant, c'est frustrant de l'acheter pour du 25ms...