Les temps réels...

Temps réel dur, temps réel mou, de quoi parle-t-on ?

On parle de temps réel lorsque la programmation peut se faire par échéance. Par exemple "j'ai besoin d'exécuter tel exécutable à tel moment". Dans le cas d'un système POSIX standard sans aucun complément temps réel, on peut presque atteindre, sur une machine peu chargée, avec une précision convenable, des délais à la seconde près... Peut-être à peu près suffisant pour un GPS piéton, mais guère mieux...

Par la suite, les extensions orientées temps réel sont arrivées, et se sont normalisées. Il s'agit essentiellement de proposer des interfaces à peu près communes pour accéder, sur les ensembles hard+soft le permettant, de meilleures précisions. A discrétion du vendeur...

Le débat central se situe alors sur la certitude du respect des échéances et du retard auquel on peut s'attendre. Prenez une application comme la video, une surcharge à un moment peut vous faire perdre une trame, on réussit en général à en reconstituer une bonne partie sans dommage. Au pire on vous fait rater une image. Prenons le cas d'un ABS : au pire on vous fait rater... un virage !!!

La question centrale donc : quelle précision suis-je sûr d'atteindre dans tous les pire cas (sauf faute de sous-dimensionnement violent de ma capacité...), quelle précision puis-je atteindre dans "juste" 90% des cas ?

Pendant longtemps, seuls les systèmes propriétaires permettaient une telle garantie. Et encore, sous certaines réserves. En effet, si un OS vous permet de désactiver les interruptions et que vous décidez sous interruptions désactivées de réordonner les particules de l'Univers, vous allez faire exploses vos échéances... Pour y parer certains OS interdisent l'accès direct aux handlers d'IT, au détriment de la performance (ex : Solaris jusque version 6). Un fournisseur d'OS avait même commis cette boulette dans un de ses propres drivers de disque...

Aujourd'hui, Linux arrive dans ce domaine, fort d'une réputation sulfureuse de "non temps réel", acquis tout au long de son histoire. La question est autant polémique que violemment pointue.

Ce qui gêne potentiellement, ce sont les intervalles de temps où un système ne peut être interrompu. Un énorme travail a été fait pour diminuer cette granularité du kernel Linux sous forme de patches à la branche 2.4, reporté en 2.5 et intégré au 2.6 (branche actuelle). Après cela, il reste à vérifier que la sélection du processus à exécuter (scheduling) prend un temps déterminé.

C'est chose faite avec le Completely Fair Scheduler du kernel 2.6.24. Reste à déterminer la latence maximale et les conditions aux limites de ce kernel. C'est ce travail que je me propose de faire et de documenter.

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