Real Time Geek

2010-01-15T12:56:00.002+01:00

Jeudi 14 janvier 2010, réunion de la DAS (Domaine d'Action Stratégique) "Informatique embarquée" du pôle Aerospace Valley, pôle de compétitivité des régions Aquitaine et Midi-Pyrénées, à Agen.

Le programme de la journée était simple : présentation des activités le matin, et 4 groupes de travail (par PF, Programme Fédérateur) l'après-midi suivi d'une restitution générale de synthèse.

Le matin, ont été présentés les calendriers, organisations, projets d'ensemble et orientations générales. L'accent a été mis sur la tracabilité et la mesure des retombées des projets subventionnés.

L'après midi, 4 PF donc : Elec(tronique), IHS (Interaction Homme Système), Diag(nostic), ISAURE (systèmes et logiciels). C'est à cette dernière que j'ai personnellement assisté.

Synthèse de Elec : Electronique et semi-conducteurs de puissance sont recherchés vivement.

Synthèse de IHS : on retient 3 éléments : méthodes de conception, IHM moderne et socle technologique.

Synthèse de PFDIAG : autodiagnostig, et on cible de l'autoréparation pour 2025 !

Je vais être plus détaille sur ISAURE.

J'étais invité, n'étant pas (encore ?) membre de ce pôle, en tant qu'intervenant dans un projet initialement créé hors du pôle mais en plein dans son activité. L'idée était du reste de prépareer les appels à la suite du projet en cours.

Force est de constater que notre projet, sur lequel nous avons jusqu'ici engagé une communication modérée, a suscité bien des interrogations. Babylone a ouvert la boite de Pandore semble-t-il...

Un très fort intérêt global pour les modèles et éléments Open Source, donc, ainsi que pour les méthodes agiles, qui du coup intéressent les autres métiers non logiciels, certification, systèmes critiques.

L'accent : se donner les moyens de montrer du produit fini et pas seulement des méthodes et des process. L'industrie les veut !!!

Synthèse : très intéressant, des discussions très riches et instructives. Mais des personnes très curieuses de Linux et de l'Open Source : à nous de convaincre !

Teaser : Linux to take off

2009-11-30T11:10:00.003+01:00

Well, fairly aggressive this title is... But by 'takeoff' I mean... embedded in planes ! For yes, one major project has emerged whose aim is to provide tools to ease DO-178 certification. Plus another project to be announced clearly aims at providing an allegedly restricted but nevertheless hard real time kernel based on Linux.

What real work is not yet done to date ? In my opinion, not much for the description, but this shortly described work means much, a big tedious but careful job to begin.

The remaining areas of concern ?

Well, as most drivers are probably following the good practise guidelines implementing interrupt handlers in 2 parts (either task queue or bottom half), a few probably remain. Targetting DO certification, only certified hardware will be of concern though. To aim at making a fully featured RT kernel, the drivers for non-certified hardware will need expertise, and some of the job might be done in the meantime.

The scheduler does have a superseded O(1) algorithm. The new algorithm, actually diverging at O(ln(n)), is however much faster than the O(1) for all real-life cases (less than 4G processus). Again, no concern here.

The malloc will need careful audit, then. This will be tedious but I am confident, as Linux use has already spread so that I am sure the audit is already fairly advanced.

Next idea lies where all the error and exceptions handling functions are. These are the other possibility of undesirable unbounded latency.

Then what ? After all the work in between have been considrerd, I think we are then almost done. Provided no-one uses the Joystick port any longer (that one can only be driver via active wait), we have then dealt with all things a processus and drivers can do : syscalls, memory, read/write, interrupts, errors...

The project in which all this work will be issued is to be announced shortly...

OpenBSD's bleeding edge pf

2009-11-18T11:16:00.002+01:00

Even though I am no networks specialist, I have been involved in the business of having to understant how OpenBSD's packetfilter, aka pf, does round-robin load balancing.

The why of this expertise was quite straightforward : as pf does round-robin exactly well and balances the load exactly as expected, the first ever target, I mean the first target when the rules are set, has been found not to be the first in the list. This remark possibly matters 0.001% of all potential pf users, but I have then been required to check pf's predictability - an unpredictable pf's first was the most seriously fact feared...

This holds for OpenBSD 4.2, ie a fairly old one, but pf code has hardly changed since, and I have not seen any change in the lines involved here.

What happens is that, using BSD's TAILQ structures and macros, pf does choose the first in the list, then iterates before selecting the target. In a word, the first target that the load balancing hits is the second in the list. It is fully predictable and safe : a behaviour well in OpenBSD's tradition.

In the end, I had to patch the program that generated our pf rules, so the first does come first in the production system...

L'embarqué au service de la sécurité ?

2009-09-08T16:05:00.004+02:00

Quelques réflexions sur la sécurité routière :

Au moment où les tristement célèbres boites noires, témoins ultimes des éléments techniques précédant les incidents de vol dans l'aviation, se font frapper d'obsolescence, n'est-il pas temps d'envisager l'utilisation des idées qui ont été à l'origine de leur création, à savoir l'analyse précise des événements afin d'accroitre la sécurité, au profit de la route ?

En partant d'un format ouvert, signé pour cacheter le contenu, d'événements datés et archivés à chaque événement ressemblant à un accident, le but serait de proposer un dispositif, techniquement dédié à l'analyse des événements pré-accident, dont le but serait principalement de détailler la responsabilité de chacun des petits oublis et/ou libertés avec le code de la route. Ceci pour fournir 2 éléments :
* Un compte-rendu exact des responsabilités engagées,
* Un relevé fiable des causes d'accident.

Ceci afin de répondre à 2 besoins : la responsabilisation des chauffeurs, d'une part, avec comme principal moteur la conduite sécuritaire car le dispositif ne serait activable qu'en cas d'événement accidentel, et un relevé juste et exhaustif des statistiques des événements déclencheurs d'accident, pour que les forces de l'"ordre" ne soient plus tentés de dire d'un accident pour lequel aucune case ne peut être cochée : "C'est la vitesse" !

Parce que j'en ai marre de serrer les fesses à chaque fois que, signifiant mon intention d'aller tout droit, je me sens suivi par un hurluberlu qui croit dur comme fer que comme la plupart des gens, je tourne à droite en omettant mon clignotant !!!

Un NetBook sympa...

2009-08-18T16:16:00.003+02:00

Depuis l'annonce de l'OpenPandora, je me suis mis à voir en ce curieux engin un fort sympathique instrument à développer en toutes occasions, avec une taille juste bonne pour la poche, et un clavier pensé pour la contrainte du compromis que les doigts de l'utilisateru ne se miniaturise pas...

Toujours sur la même techno sur base ARM (un ancien de Cambridge comme moi est nécessairement sensible à leurs miracles), le TouchBook de Always Innovating...

Allez, plus qu'à rêver de la même chose sur base Cortex A9... En attendant, jolie bête : Reprenant la taille des NetBooks les plus sympas à mon avis (9" : en dessous, la résolution de l'écran chute à un simple WVGA, au-dessus on ne gagne plus rien de concret), ajoutant une jolie innovation sur le coup du clavier détachable, ce combiné tablette-ordinateur sous Linux est le gadget de geek qui me fait le plus envie à l'heure actuelle !

http://www.alwaysinnovating.com/touchbook/

Latence, préemptibilité and al

2009-07-20T10:22:00.002+02:00

C'est dit, je me consacre du temps cet été pour me "muscler" au niveau du scheduler et des éléments internes du kernel. Le but : apporter une petite touche avec l'esprit temps-réel. Je ne serai pas le premier à le faire (ni le dernuer j'espère), mais ce serait tellement chouette un kernel RT...

Si quelqu'un a un pointeur pour des analyses au sujet de FreeBSD sur ce point je suis preneur :-)

Hors sujet

2009-06-11T13:29:00.003+02:00

Petite parenthèse 100% hors sujet.
Dans l'actuelle mouvance philosophico-écologique, ne crachons pas sur ce qui est fait jusqu'ici, on a fait bien plus d'effort en 10 ans que pendant tout le reste de l'humanité, le tout grâce à une prise de conscience dont on finissait par désespérer.
Cependant, chassez le libéral, il revient au galop, tout s'est fait en se concentrant sur une seule donnée, puisque comme chacun sait notre monde perçu par les financiers n'existe qu'en 1 dimension... Et la dimension qui a été choisie s'appelle "CO2".
Or il est un domaine où la pollution autre que le CO2 a un aspect manifestement plus nocif et dommageable que le CO2 : les moteurs à combustion spontanée (nommés du patronyme de son inventeur "Diesel"). En effet, une étude suédoise attribue aux échappements du Diesel en Europe presuqe autant de morts par cancer du poumon que... l'amiante, interdite chez nous depuis quelques années déjà !
On pourra dire qu'il s'agit encore d'une avancée écologique, puisque les premiers touchés par les dommages en question sont les mammifères vivant en zône urbaine, à savoir les homo erectus citadinus, aussi les pires pollueurs de la planète : autorégulation...
Je n'adhère pas.
Exigeons la prise en compte des émissions de particules fines (non filtrées par les très mercantiles "Filtres à Particules") dans le calcul de la puissance fiscale et de la taxe pollution.

La latence, tout est là...

2008-11-24T18:40:00.002+01:00

Les efforts de Ingo Molnar ont été momentanément mis en attente avec la suppression du Big Kernel Lock apparu pour (de mémoire) le 2.6.27. Tout ça pour arriver (enfin) à maîtriser la latence.

Aujourd'hui, où en est-on exactement ? A part que la plupart des handlers se contruisent avec la problématique de latence en tête, il reste des approches contradictoires, ou plus exactement "nombrilistes" : si l'on veut que "son" driver soit temps réel à latence la plus faible alors il faut que tous les autres drivers aient une latence sous interruption maîtrisée (donc souvent en 2 parties) mais que l'on écrive son propre driver en monobloc... Rassurons-nous, la différence entre les deux reste très faible.

A voir en pratique...

Prochaine étape : tickless kernel sur OpneMoko et Pandora.

FreeRunner

2008-08-28T12:51:00.003+02:00

Ca y est, je l'ai ! un téléphone dont tout l'ensemble logiciel est en très forte majorité Open Source. Seule exception, la pile GSM, intégralement contenue dans une puce pour éviter les soucis liés au protocole (on ne va tout de même pas envoyer un faux IMSI pour faire facturer le voisin...).

Pour le reste, résolution intéressante, réactivité convenable, pas mal du tout le QTopia.

L'aspect technique ? Un kernel 2.6.22.x patché, donc pas de tickless kernel. C'est certainement un des éléments qui expliquent une autonomie faiblarde. Une saisie, basé sur un tandem clavier / dictionnaire prédictif, divise la communauté. Bref, le travail a besoin d'encore un peu de finition.

Première Matinale Red Hat

2008-06-25T07:18:00.000+02:00

Hier (mardi 24/6) matin, j'ai eu l'opportunité d'être convié à une Matinale Red Hat, la première du nom en fait. Le but : présenter toutes les nouveautés de l'entreprise au Fedora rouge dans le domaine de la virtualisation, ainsi que 2 invités de marque, Intel pour montrer la participation du fondeur aux technologies de virtualisation, et un cas concret de mise en oeuvre de virtualisation, présenté par des membres de l'équipe de DSI de Pages Jaunes.

Concernant la virtualisation, à part un engagement de Red Hat avec Xen jusqu'en 2014 et des développements poussant aujourd'hui des technologies du kernel 'Vanilla', au premier chef kvm, l'accent est surtout mis sur la carence actuelle des logiciels libres de virtualisation, que j'avais identifiée avec mon collègue D. Hannequin dans le Livre Blanc publié par LINAGORA sur le sujet : les outils d'administration de parc virtuel. D'excellentes nouvelles donc.

La fin de leur présentation signalait aussi une annonce nommér MRG : Messaging Realtime Grid, basé sur Linux, série 2.6.24. La mise en avant d'un produit annoncé temps réel dur basé sur un kernel "vanilla"...

J'avais ouvert ce blog en espérant merttre en évidence que cela était en effet possible, mais le résidu de BKL (Big Kernel Locks) dans le kernel, et l'évaluation de A. Morton à environ 10 ans de travail pour s'en débarrasser totalement m'avait un peu ramené à la dure réalité : not yet.

Et toujours pas d'ailleurs, en réalité, mais qu'un des plus gros industriels impliqués dans le noyau s'y engage, c'est une excellente nouvelle. On tient les paris... Pour 2009 ?

Latences...

2008-05-05T14:41:00.000+02:00

Tout d'abord la référence : la programmation temps-réel a ses normes : POSIX 4d9, devenu POSIX 1003.1b-1993 puis POSIX 1003.1i-1995. Totu cela indique comment coder une application utilisateur qui se comporte d'une certaine manière et quelles sont les obligations et/ou bonnes partiques d'un OS en terme de réponse.

Du point de vue d'une application, le temps est continu, la seule chose à prendre en compte est que le temps entre deux "gettimeofday" est foncièrement indécidable. L'important donc pour un code en mode utilisateur, c'est essentiellement de pouvoir réquisitionner le processeur dans des temps bornés (réaction à sollicitation), ou en temps prévu (interval timer).

Or cette réquisition va se faire moyennant un certain délai, entièrement du ressort de l'OS : le temps d'interrompre une tâche (user ou kernel) en cours, le temps de sélectionner la tâche à éxécuter, le temps de reprendre.

Concernant la reprise, le temps peut être considéré comme à peu près constant, il s'agit d'un temps de commutation de contexte très peu dépendant du processus à réactiver (la seule dépendance, liée à la présence ou non du code à réactiver dans le cache, n'est pas maitrisable). Sur ce point on peut donc trouver un temps majorant assez simplement.

L'interruption d'un processus utilisateur est de la même veine. Dans le cas particulier, donc, d'un processus utilisateur à interrompre, la qualité temps réel de la réquisition du processeur par le système pau profit d'un autre processus est complètement liée à la qualité temps réel de la sélection du processus à sélectionner (le scheduler).

Cas un peu plus complexe mais très fréquent : la sollicitation arrive sous forme d'une interruption. En rajoutant l'hypothèse que le processus en cours est un processus utilisateur. C'est un cas qui peut se ramener rapidement au précédent, puisque la commutation de tâches dans un système à temps partagé se fait en programmant un générateur d'interruptions (timer). On a donc "simplement" rajouté le temps de traitement particulier de l'interruption considérée - et ôté la durée du handler du timer.

Les *vrais cas difficiles c'est quand on interrompt un bout de code kernel.

O temps suspends ton vol...

2008-04-21T14:32:00.000+02:00

Je viens de voir à l'occasion de la sortie du kernel Linux 2.6.25 l'existence de l'outil latencytop. De quoi au moins outiller mes propos, pour les latences que l'outil saura mesurer.

Après parcours de la liste des innovations de la 2.6.25, il semble que l'effervescence se soit calmée pour la partie scheduler. Tant mieux, il y a tant à dire pour la 2.6.24 !

Les latences possibles que j'imagine au niveau kernel (les freins à une latence faible) ?

- tout d'abord le matériel. Il est illusoire de demander à un ARM2 à 8MHz d'obtenir une latence identique à un Core2 duo dont la fréquence interne est facilement 250 fois supérieure ! De même les accès RAM et les débits RAM ont profité d'une amélioration spectaculaire ces 10 dernières années et les systèmes auxquels on demande les meilleures perfs RT ne sont pas les machines dernier cri...

- ensuite le codage interne du kernel. Blocage sous Mutex, Ordonnaceur trop long, interruptions désactivées trop longtemps sont les principales causes d'accroissement de latence. Un handler d'IT mal écrit peut décider de la latence complète du système. Ce n'est pas propre à Linux, un vendeur d'OS temps réel l'a appris à ses dépends sur son propre driver disque dur !

- Enfin l'utilisation du système. une machine qui croule régulièrement sous la charge, dimensionnée pour accepter juste la charge, ne sera peut-être pas en mesure de tenir systématiquement uen latence faible. On ne peut exiger d'une machine prévue pour bosser 10 secondes à 110% de ses capacités de prétendre avoir un comportement temps réel pendant cette surcharge sans risquer de voir certaines piles déborder (au mieux), certaines latences diverger (au pire).

Donc on commencera à parler de temps réel sous les conditions suivantes :

- Les erreurs de codage manifestes sont exclues,

- L'erreur de sous-dimensionnement pour de longs intervalles est écartée,

- On demande au matériel des latences qu'il a une chance de tenir.

Les temps réels...

2008-03-10T13:57:00.000+01:00

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

2008-03-04T11:30:00.000+01:00

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