Finalement, la petite seconde intercalaire du week-end dernier n’est pas passée si inaperçue que cela, elle a même provoqué le crash de plusieurs serveurs Linux…
J’ai poursuivi les tests entamés dans l’article précédent de cette série, en laissant tourner pendant de longues durées un programme qui vérifie les fluctuations d’un timer logiciel à 100 micro-secondes. Voici quelques résultats obtenus sur la Pandaboard avec un noyau Linux 3.4.1 en version « vanilla » pour commencer, puis avec l’application d’un patch Linux-rt par la suite.
Vous le savez peut-être, l’IERS (International Earth Rotation and Reference Systems Service) a décidé d’ajouter une seconde intercalaire (leap second) à la fin de la dernière minute du mois de juin. Ces secondes, que l’on insère tous les deux ou trois ans à la fin du mois de décembre ou de juin (la dernière date du 31/12/2008) servent à ajuster l’heure officielle avec la rotation de la terre. Cela à commencé il y a quarante ans, le 30 juin 1972.
Avec Bash, la complétion des commandes, noms de fichiers, etc. grâce à la touche « tabulation » est très pratique et je l’utilise en permanence. En pratique mon auriculaire gauche y trouve presque sa position de repos naturel lorsque je travaille en ligne de commande. C’est aussi un moyen très efficace de perdre des fichiers involontairement. Voici ce qui vient de m’arriver.
Dans le précédent article, nous avons examiné les possibilités de fonctionnement en continu d’une carte Pandaboard. Il s’est avéré que l’ajout d’un dissipateur thermique était indispensable pour maintenir un régime permanent à 100% du CPU.
Nous allons dans cet article observer le comportement d’un timer logiciel Linux sur cette carte sous une haute charge – tant logicielle qu’en interruptions – et mesurer les fluctuations maximales.
Depuis quelques jours, les articles de ce site, comme la plupart de ceux basés sur WordPress, souffraient d’un léger défaut : un espace insécable se trouvait inséré automatiquement par erreur avant les apostrophes produisant un rendu visuel un peu curieux.
Je conseille souvent à mes clients de faire des tests de longues durées pour leurs systèmes temps réel avec des charges extrémement élevées, tant en interruptions qu’en processus, afin de valider la bonne tenue de l’architecture choisie. Il s’agit d’aller sensiblement au-delà de la charge prévue lors de la conception, et de laisser le système en fonctionnement le plus longtemps possible (plusieurs jours au minimum) afin de pouvoir observer les cas rares où les latences maximales sont atteintes.
Nous allons réaliser ce genre de torture test pour la Pandaboard.
Je tiens à apporter une précision concernant mes récentes mésaventures avec des Pandaboard.
Ce n’est pas moi qui l’ai grillée, c’est Doug ! La preuve en image.
Et Doug est certes plein de bonne volonté mais depuis qu’il a quitté la R.A.F., il n’est plus très au fait des technologies modernes.
Suite à un petit commentaire de Yoann Sculo concernant l’avant dernier article, j’ai eu envie de détailler un peu le fonctionnement du multiplexage des GPIO sur un processeur OMAP (comme celui de la Pandaboard), et les paramètres auxquels nous pouvons avoir accès par l’intermédiaire du système de fichiers debugfs.
Nous avons vu dans les articles précédents comment écrire sur une broche de sortie du connecteur d’extension de la Pandaboard depuis l’espace utilisateur, puis depuis le kernel. Nous avons également réussi à lire l’état de broches GPIO d’entrée. Cette fois, nous allons améliorer cette lecture en gérant l’occurence d’événements par l’intermédiaire d’interruptions.
