Si vous avez suivi mon petit "tutorial" il y a quelques semaines vous devriez avoir grâce à votre Raspberry Pi et une simple webcam, un système de vidéo-surveillance pleinement fonctionnel, autonome, et avec détection de mouvements.

"Pleinement fonctionnel" ? Vraiment ? Si je me fie à mon expérience personnelle, c'est loin d'être le cas.

Troubles de l'alimentation

J'ai remarqué quelques jours après la mise en place de ce système que mon RPi devenait – après un laps de temps aléatoire (quelques heures à quelques jours) – injoignable, que ce soit par SSH ou par HTTP. Il était alors nécessaire de le rebooter méchamment. En consultant les logs et notamment /var/log/kernel.log, j'ai noté de nombreux signalements de défauts d'écriture sur le système de fichiers (la carte SD).

$ tail /var/log/kernel.log

Apr 2 20:12:11 comeye kernel: [42422.489985] mmcblk0: error -110 transferring data, sector 6721728, nr 96, cmd response 0x900, card status 0x0
Apr 2 20:12:11 comeye kernel: [42422.490989] end_request: I/O error, dev mmcblk0, sector 6721736
Apr 2 20:12:11 comeye kernel: [42422.491051] Buffer I/O error on device mmcblk0p3, logical block 37657
Apr 2 20:12:11 comeye kernel: [42422.491068] lost page write due to I/O error on mmcblk0p3
Apr 2 20:12:11 comeye kernel: [42422.491095] end_request: I/O error, dev mmcblk0, sector 6721744
Apr 2 20:12:11 comeye kernel: [42422.491145] Buffer I/O error on device mmcblk0p3, logical block 37658
Apr 2 20:12:11 comeye kernel: [42422.491163] lost page write due to I/O error on mmcblk0p3
Apr 2 20:12:11 comeye kernel: [42422.491188] end_request: I/O error, dev mmcblk0, sector 6721752
Apr 2 20:12:11 comeye kernel: [42422.491206] Buffer I/O error on device mmcblk0p3, logical block 37659

Ces défauts entraînaient parfois des corruptions de données, qui à leur tour obligeaient à terme le noyau à remonter la ou les partitions concernées en lecture seule. Une fois la partition / en lecture seule, je pouvais obtenir l'invite de login en SSH mais impossible de m'identifier : la connexion était toujours coupée à l'ouverture de la session.

Après d'intensives recherches plus ou moins fructueuses, j'ai fini par déduire que ce comportement résultait de défauts d'alimentation, probablement causés par la webcam qui "tirait" trop sur l'USB. La seule solution dans ce cas était de la brancher sur un hub USB alimenté indépendamment, relié ensuite au Pi. Mais la plupart des hubs qu'on trouve sur le marché ne respectent pas les spécifications qui imposent que celui-ci ne doit pas alimenter l'appareil auquel il est relié (c'est-à-dire l'appareil "maître", les périphériques eux doivent être alimentés bien sûr). Si la plupart des ordinateurs ne trouveront rien à redire à un hub présentant cette anomalie, le Raspberry Pi lui ne l'entend pas de cette oreille, et cela entraîne des erreurs de connexion avec les périphériques (donc ma webcam). Strictement inutilisable en l'état.

J'ai pu d'ailleurs vérifier cela avec un hub pas cher de cette célèbre marque discount qu'est Heden : le simple fait de brancher le RPi sur le port d'entrée allumait les diodes d'activité, signe que le hub lui envoyait du courant, ce qui est potentiellement dangeureux pour la carte (pour info, le terme anglais à rechercher est "backfeed" : si ça backfeed c'est pas bon).

Troubles du... heu, transit

Heureusement, il existe une liste des hubs USB notés "Raspberry Pi-compliant", parmi lesquels j'ai choisi et commandé celui proposé par le site anglais de ModMyPi. Après deux semaines d'attente sans réception, l'envoi d'une deuxième exemplaire par ModMyPi (très sympa pour le coup) et la non-réception de celui-ci après trois semaines, j'ai finalement commandé le même modèle sur eBay, également expédié d'outre-Manche. Et je l'ai reçu ! (à vrai dire je commençais un peu à désespérer...)

Mes lectures concernant ce modèle indiquaient qu'il était capable d'alimenter à la fois le RPi via un des quatre ports, en plus des autres périphériques qu'on pouvait y brancher. Le transfo d'origine du RPi devenait donc inutile, ce qui permettait d'économiser une prise secteur (et ce n'est pas du luxe, tout geek vous le confirmera !). J'ai donc effectué le branchement pendant que dd recopiait une image saine du système sur la carte SD, pour partir sur de bonnes bases.

Un petit méli-mélo de câbles plus tard, le petit ordinateur, le hub et la webcam étaient reliés et fonctionnels.

Une solution à l'hub-ifidus actif

Ce système fonctionne maintenant depuis quelques jours et, sans vouloir crier victoire trop vite, je pense que cela a bien résolu les problèmes d'instabilité. Je n'ai strictement plus rien dans les logs indiquant des corruptions de données, alors qu'il suffisait aurapavant de 24h maximum pour les voir apparaître. Si vous subissez les mêmes symptômes, essayez ce hub (ou un autre de la liste) et cela devrait être suffisant pour les faire disparaître.

Il est par contre assez décevant de constater qu'un défaut d'alimentation, plutôt que d'engendrer des problèmes de communication avec le périphérique responsable, provoque sur le Raspberry Pi une défaillance d'organes "vitaux" tels que le lecteur de carte SD, seule mémoire de masse disponible. La conséquence étant, comme j'en ai fait l'expérience, de rendre le mini ordinateur instable et finalement de le planter (sans parler des données potentiellement perdues au passage), cela fait sérieusement douter sur la fiabilité d'un système "embarqué" dont il serait la base. Je pense ici à une installation fonctionnant 24h/24 et à l'accès peu aisé, type caméra de surveillance extérieure, capteur météo, etc. Dommage.

Avant de terminer, je tiens à mentionner qu'il est fortement conseillé de mettre en place le watchdog de Linux sur un tel système. Mais dans mon cas cela ne servait à rien car celui-ci n'était que rarement totalement planté (seulement inaccessible par le réseau), et quand il l'était le reboot ne permettait pas de reprendre le contrôle car les dommages sur le système de fichiers pouvaient avoir touché des fichiers vitaux et empêcher ainsi le boot.
Il est cependant important de noter qu'il existe sur le RPi un watchdog matériel qui permet de rebooter automatiquement la carte quand le système est complètement planté. Pour faire court, il s'agit d'un compteur incrémenté régulièrement par un composant externe au CPU et qui, s'il atteint une valeur limite préalablement définie, délenche un hard-reset. L'OS a donc pour tâche de remettre ce compteur à zéro à intervalle régulier afin de signaler qu'il répond toujours. S'il est planté, le compteur ne sera jamais remis à zéro, ce qui entraînera à terme le hard-reset par le watchdog. La durée limite du watchdog présent sur le RPi est de 16 secondes.

Je termine enfin le récit de mes aventures avec mon vieux PC "Ancient" à base de 486 DX2. Jusqu'ici j'ai pu expérimenter quelques soucis inhérent à cette génération de matériel :

• La pile CMOS avait tout d'abord rendu l'âme bien des années plus tôt, et trouver le bon modèle m'a posé quelques problèmes car ce n'est pas le CR2032 bien standard de nos jours.
• Ensuite, il s'est avéré que 6 Mo de RAM n'étaient pas suffisants pour charger le programme d'installation de Slackware Linux 8.1 datant de 2002. J'ai dû acheter deux barrettes de 8 Mo pour pouvoir passer cette étape avec succès.
• Une fois le programme d'installation chargé, et comme aucun médium autre que la vénérable disquette 3,5" n'est disponible sur la machine, la seule solution pour procéder à la copie des paquets était le montage NFS par le réseau. Et j'ai ainsi réalisé que faire fonctionner une carte réseau ISA "Plug'n'Play" pour Windows n'était pas sans prise de tête sous Linux.

Mais je n'étais pas au bout de mes tribulations...

Si vous avez raté le début :

Les aventures d'un 486 DX2 au XXIème siècle (1ère partie)

Les aventures d'un 486 DX2 au XXIème siècle (2ème partie)

Les aventures d'un 486 DX2 au XXIème siècle (3ème partie)

Les aventures d'un 486 DX2 au XXIème siècle (4ème partie)

X(Free86)

Une fois toute la configuration de base effectuée (réseau, daemons, etc.) je me suis attaqué à ce que je pressentai être un gros morceau : la configuration du serveur X (plus exactement XFree86 version 4.2.0, 2002 oblige), et cela avec le chipset intégré : un Cirrus Logic GD5422-800-D (proche de ce cette carte).

Un essai innocent avec la commande

$ startx

me retourne une erreur, jusque-là rien d'étonnant. Je commence à explorer les fichiers de configuration pour adapter tout ça et obtient "plutôt rapidement" en utilisant le pilote "vesa" ce qui ressemble à un affichage graphique. Pour information, il faut compter environ 20-30 secondes entre le lancement de la commande startx et l'apparition du curseur à l'écran, temps durant lequel on imagine aisément le swap qui turbine à plein régime trahi par le grattement incessant du disque dur.

Vérification faite, la résolution est de 320x200. Sur un écran de 19" tel que j'utilise cela se traduit par un curseur qui a la taille de ma souris, et des boutons qui semblent plus proches de ceux trouvés sur les appareils de la marque Playskool que sur un ordinateur.

(Pour vous faire une idée, affichez la capture d'écran ci-contre en plein écran, en zoomant de sorte qu'elle prenne toute la largeur de celui-ci)

Un autre problème s'impose aussi brutalement : le curseur reste désespérément immobile malgré mes mouvements, seul le clavier semble répondre. Le point positif est qu'il ne s'agit donc pas d'un crash mais simplement d'un mauvais fonctionnement de la souris seule. Sur les deux problèmes, je décide de commencer par la souris : en effet, cela ne sert à rien d'avoir une résolution HD (ha ha) si aucun curseur ne permet l'interaction.

USB et PS/2 sont sur une galère...

Je vérifie la souris sur une autre machine : elle fonctionne. De toute manière, c'est elle que j'utilisais sur Windows 95... Hum. Attends voir, j'ai souvenir d'un problème de souris sur Windows justement depuis que j'ai resuscité cette machine. Mais aucune chance que cela vienne de la souris, non, il n'y a qu'à la regarder : une souris toute neuve, optique, USB évidemment, mais j'y ai mis un adaptateur vers PS/2 pour la rendre compatible... du moins je crois ?

En fait, quand on se renseigne un peu plus sur le fonctionnement du port PS/2 tel qu'il était à l'origine, rien ne permettait de faire fonctionner un périphérique USB avec un simple adaptateur passif comme le mien. En effet, le protocole est bien particulier et ne ressemble en rien à celui utilisé par l'USB. Sur les configurations "récentes" comprenant le protocole USB, le pilote/noyau est simplement capable de s'adapter au périphérique branché et de basculer sur le protocole adéquat.

Mais ici, point de bascule non non. Je n'ai pas poussé mes investigations plus loin mais il semblerait que cela s'explique par le fait que le module noyau pour la gestion de l'USB n'est pas installé sur mon Linux – normal en même temps, pour la machine c'est un protocole encore inexistant. Une souris USB reste donc inconnue et inutilisable. Il faut obligatoirement passer par une vraie souris PS/2 (enfin, peut-être pas "obligatoirement", mais plus aisément). Heureusement, j'ai encore ça dans mon fouillis qui me sert de réserve de matos.

Une fois le changement effectué (après avoir rebooté évidemment, le branchement à chaud restant déconseillé sur ce type de port), voilà mon curseur qui s'anime enfin à l'écran quand le serveur X tourne. On avance !

Une bonne résolution...

Restait donc maintenant à obtenir une définition d'écran plus correcte, ce qui était possible en théorie puisque Windows 95 la proposait : du merveilleux 640x480, voire du 800x600 (mais là sous Windows je restais bloqué en 16 couleurs). J'ai donc commencé à bidouiller les fichiers de configuration, lister les pilotes les plus adaptés pour le chipset vidéo, notre fameux Cirrus Logic GD5422, et les essayer un par un (avec le temps de boire un petit thé entre chaque redémarrage du serveur X...). Après de nombreux essais, je me résigne à rechercher sur Google-est-ton-ami des informations sur ce Mathusalemique matériel et son support sous Linux.

Et voilà que grâce à la machine à remonter le temps qu'est le Web, je tombe sur des archives de "forums" datant de la fin des années 90, plutôt marrantes à parcourir. Il s'agit en fait d'archives de mailing-lists, récupérés par des... chinois ?, mis sous forme de forums et hébergés par leur soin (essayer une URL invalide pour constater que c'est un serveur Microsoft IIS en chinois qui répond).

Mais cette page ne m'en apprendra pas plus. En revanche, et après moultes redirections z'et indirections, je tombe sur une page poussiéreuse au contenu plus que pertinent (et triste) : http://www.xfree86.org/4.2.0/Status9.html. Le chipset CL-GD5422 ne serait tout simplement plus supporté à partir de la version 4.2.0 de XFree86 ! C'est bien ma veine. Inutile donc d'essayer quoi que ce soit de plus en l'état.

Downgrading, please wait...

J'envisage alors la potentielle prise de tête s'il faut que je downgrade XFree86 de la version 4.2.0 vers la version 3.3.6 (dernière version stable de la branche 3.x). Gloups.

Mais c'était sans compter que la Slackware est pleine de ressources, notamment en ce qui concerne les vieux machins dépréciés (troll spotted). En me renseignant un peu, je découvre que le répertoire élégamment nommé "/pasture" du CD de la Slackware (toujours monté via NFS depuis mon serveur) contient quelques packages de précédentes versions stables des logiciels installés automatiquement. Et parmi eux, je vous le donne Luc (non il s'appelle Émile - ah oui) je vous le donne Émile : XFree86 3.3.6 !. Un petit coup d'oeil au README associé et mon écran reflète alors un sourire de joie. Extrait :

These are the X server packages from XFree86 3.3.6.  If you have a video card that is not working under XFree86-4.x, you can try installing the appropriate 3.3.6 server on top of your XFree86-4 installation to see if that gets it working.  All of these servers will work fine with the newer libraries that are installed with XFree86-4.x.

Mais c'est la fête dites-moi ! D'après ce texte je peux simplement installer les packages de la version 3.3.6 par-dessus ceux de la version 4.2.0 déjà présente. Y'a plus qu'à !

Un petit

# installpkg *.tgz

dans le dossier et quelques minutes de grattements stressants du disque plus tard, l'installation est faite. Je n'ai plus qu'à redémarrer et retenter la configuration du serveur X.

Cette fois, je peux utiliser XF86Setup, un petit utilitaire "graphique" (oui bon, le rendu est simple hein) et simplement suivre le guide pour sélectionner la souris, le clavier, le chipset vidéo, la définition de l'écran et la configuration du moniteur (fréquence). Sur ce dernier point j'y vais un peu au hasard car évidemment les écrans TFT n'étaient pas trop courants à l'époque. Après quelques tentatives infructueuses j'arrive enfin à obtenir un magnifique affichage Hache-Dé en 800x600 et 256 couleurs ! Merveilleux !

 

C'est le maximum que je pourrai atteindre avec ce matériel car le chipset est équipé de 512 Ko de RAM. Comme le rappelle cette page, la quantité de mémoire équipant le chipset détermine les limites en termes de définition et profondeur de couleur qu'il est possible d'utiliser. Un petit calcul nous apprend qu'avec une profondeur de couleur de 8 bpp (appelée communément "8 bit") nous consommons 800x600x1 (1 car 8 bits = 1 octet) = 480 000 octets ou 480 Ko, soit 94% du total. On ne peut simplement pas trouver une définition supérieure standard qui ne dépasse pas la limite de 512 Ko imposée par le matériel.

À tout hasard, pourrais-je passer en "Haute couleur" (16 bit) en abaissant la définition à 640x480 ?

Réponse : non, car 640x480x2 = 614 400 octets. Il me faudrait pour cela le modèle équipé de 1 Mo de RAM (et qui existe / a existé comme le mentionne ce manuel datant de 1995).

Petit tour sur l'app-store... (ha ha)

J'ai (re)testé un peu tous les environnements de bureau proposés (sauf KDE), mais j'avoue avoir une faiblesse pour WindowMaker⁽¹⁾. C'est surtout un des rares à être suffisamment léger pour être utilisable. J'ai bien sûr essayé Gnome (en version 1.4 ici), mais le bureau n'est chargé qu'après 5 minutes avec un load average qui monte à 6, et un délai de réaction d'au moins 30 secondes à chaque action (ici action = clic pour ouvrir un menu), donc clairement ce n'est pas adapté.

Afin de voir à quoi ressemble le rendu d'une page web contemporaine avec un navigateur de cette époque (et une machine encore plus vieille), je décide de lancer la "suite" Mozilla – par ailleurs en version 1.0 sur cette mouture de la Slackware.

Verdict : la navigation ne va tout simplement pas être possible. Ou alors il faut renommer "navigation" en "traversée de l'Atlantique à la rame, que dis-je, à la cuillère à café". Il aura fallu plus 800 secondes pour lancer l'application et terminer le rendu de la page www.mozilla.com ! Je n'ai pas eu à chronométrer, simplement à lire le temps de génération de la page indiqué dans la barre d'état...

Étrangement par contre la mise en forme est plutôt respectée. J'imagine que le site de Mozilla est plutôt bien construit et reste compatible avec les anciens navigateurs (à condition qu'ils respectent les standards évidemment).

Hum, bon, c'est pas avec ça que je vais avoir une idée plus concrète. Je ferme donc Mozilla et revient (cinq minutes plus tard...) sur le bureau. Je me rappelle alors que j'ai commencé à utiliser Opera sur Windows à peu près à cette époque – grâce à la version 5 obtenue dans le CD vendu avec un magazine – et j'avais été tellement bluffé de la réactivité et des fonctionnalités offertes par ce navigateur que j'en avais immédiatement lâché Internet "Evil" Explorer. Si ça se trouve, je pourrais obtenir un peu le même genre d'effet ici sur Linux. Mais pour cela il faut que je trouve un moyen d'installer – et d'exécuter – une version adaptée à ma configuration...

Pour trouver une archive c'est facile : Opera a eu la bonne idée de conserver l'intégralité de toutes les versions sur un FTP dédié : http://arc.opera.com/pub/opera/linux/505/. À nouveau un petit tour dans la machine à remonter le temps !

Je choisis le fichier  opera-5.05_tp1-static_qt-libnpp-0.1.1.x86.tar.gz car c'est la version la plus générique et dont les biblitohèques sont compilées statiquement : en gros c'est un blob avec tout dedans, donc pas de souci de dépendance avec telle ou telle version de telle bibliothèque à prévoir (si tout va bien). Un petit script shell est prévu pour installer l'application de manière didactique, je n'ai qu'à le suivre. Je lance ensuite la commande

$ opera

et quelques... dizaines... de secondes plus tard je retrouve l'interface oubliée d'Opera 5.05 (avec sa petite bannière de pub car il n'était pas encore gratuit !).

Le chargement des pages est tout de suite plus véloce : il faut à présent compter entre 45 et 60 secondes pour des pages simples. Mouais. Fallait s'y attendre.

Verdict final

Mais tout ceci reste bien laborieux, si bien qu'il serait difficile d'imaginer réutiliser une machine pareille aujourd'hui. J'ai également testé rapidement le serveur Apache avec PHP et une petite page simple : on évite le timeout certes, mais la réponse est vraiment très longue à venir. L'utilisation ne serait-ce que du terminal est sujette à des microfreezes pendant lesquels on entend clairement le disque qui subit le swapping, la faute à une quantité de RAM trop faible. Et c'est d'ailleurs ce qui semble être le facteur le plus limitant ici : le débit de la RAM et sa taille. Je pense qu'avec 64 Mo il serait possible d'obtenir une petite machine qui pourrait servir de serveur Web léger (en évitant Apache évidemment) ou de serveur mail.

Mais avec seulement 16 Mo, il n'y a quasiment plus de mémoire libre une fois le système démarré, alors comment imaginer lui demander de faire plus ?

Côté affichage, la configuration souffre de son âge et de son chipset d'entrée de gamme. L'environnement graphique "récent" qu'est WindowMaker, bien qu'extrêmement léger, accuse une lenteur insupportable. Comme la navigation sur le web n'est clairement pas à la portée de la machine, je me suis dit que j'allais au moins tester un traitement de texte simple : Abiword, dans la version fournie avec la Slackware 8.1. Mais là aussi c'est un échec : le texte peine à suivre ma frappe (pourtant souvent laborieuse) et s'affiche avec un fort retard. De toute manière l'interface générale reste elle aussi trop pataude pour être utilisable.

Pas vraiment de surprise donc, il s'agit bien des performances d'une machine du milieu des années 90 sur laquelle on a mis un système d'exploitatoin du début des années 2000. Il ne viendrait à l'idée de personne d'installer Windows XP sur un PC vendu avec Windows 3.1 (l'OS d'origine avant que je n'y mette 95), et pourtant c'est le pari audacieux (et inutile, mais sooo geek) que je me suis lancé. Et au final,  malgré le choc générationnel hardware/software, GNU/Linux permet d'éviter l'échec complet et propose une machine – qui bien que très lente – reste stable et parfaitement utilisable en headless ou pour quelques applications graphiques très simplistes. De manière plus hypothétique, on pourrait aussi la proposer à une personne – un enfant pourquoi pas (mais geek forcément) – pour découvrir le C ou d'autres langages bas-niveau et les interactions possibles avec le matériel, plus simples à appréhender sur un PC de cette époque que sur une configuration actuelle.

Reste que j'ai pris beaucoup de plaisir à bidouiller du vieux matos de ce genre et à résoudre tous les problèmes qui se sont posés tout au long de cette expérience, ce qui était bien mon but au départ. Je suis donc complètement satisfait du voyage et espère que ce récit vous aura autant plu à lire que moi à l'écrire.

(1) Dont j'apprends avec stupéfaction que la dernière version est sortie en janvier 2013, incroyable.

Non, ce blog n'est pas mort. Moi non plus d'ailleurs. J'ai simplement dû faire face à une charge de travail assez conséquente ces dernières semaines (voire ces derniers mois) qui a engendré son taux de stress et de démotivation et entraîné une impossibilité de poursuivre le récit de mes péripéties geekiennes.

Mais cela pourrait changer.

Je suis actuellement sur plusieurs idées d'articles qu'il va falloir que je rédige :

• la 5ème et dernière partie des Aventures d'un 486 DX2 au XXIème siècle (qui devrait être plus courte car je n'ai plus grand chose à dire (EDIT : raté))
• la suite de l'article sur le Raspberry Pi, avec notamment des scripts pour lighttpd/PHP mais je suis un peu bloqué pour l'instant (voir plus bas)
• un petit utilitaire que je code en Java actuellement et qui permet de rechercher des doublons de fichiers selon différents critères

Je suis par contre bien embêté aujourd'hui car mon Raspberry Pi fonctionne très aléatoirement depuis quelques semaines. L'effet le plus remarquable est une corruption des données sur la carte SD, ce qui conduit au bout de quelques jours à un perte complète de contrôle car le démon SSH tombe. Je suis alors obligé d'ôter la carte, de réparer le système de fichiers depuis une autre machine et de rebooter le RPi. C'est plutôt frustrant.

Après une longue investigation, j'ai déduit que cela provenait de la webcam qui tire trop de courant de la carte et n'en laisse pas suffisamment au SoC. J'ai donc testé de la brancher sur un hub USB PasCher® mais elle ne fonctionne alors plus du tout (entre autre car le hub renvoie aussi du courant vers la prise USB source... vive la qualité). J'attends donc la réception du hub adapté commandé sur ModMyPi mais le premier colis a été perdu en route.

À très bientôt, si tout va bien !

 Ça y est, je suis moi aussi dans le vent comme disent les jeunes, j'ai reçu ma Framboise Pi ! (Raspberry Pi pour les anglophones).

Quoi ? Vous ne savez pas ce qu'est un Raspberry Pi ? Alors petit résumé pour les gens qui ont vécu dans une caverne sans ADSL durant les 12 derniers mois.

Mini-carte à mini-prix

Le Raspberry Pi modèle B (le mien) est un ordinateur monocarte équipé d'un processeur ARMv6 (un Broadcom BCM2835 cadencé à 700 MHz) et conçu par la Raspberry Pi Foundation au Royaume-Uni. Il ne pèse que 45g (!) et est équipé du strict minimum au niveau de la connectique :

• 2 ports USB 2.0,
• 1 port HDMI (seule sortie vidéo pour moniteur informatique),
• 1 port RCA Composite (sortie "TV"),
• 1 sortie audio Jack,
• et enfin 1 port Ethernet 10/100.

Il est alimenté en 5V par un port micro-USB et possède 512Mo de RAM, ce qui est très confortable pour une machine pareille. On trouve également un port GPIO qui permet de relier la carte à des composants externes ou circuits de toutes sortes et ainsi accroître ses fonctionnalités.

Quand des informations sur le modèle A de cette carte sont sorties fin 2011, j'avoue avoir hésité un peu malgré le faible prix proposé (25$ soit à peine 18€ HT). "Que vais-je en faire ?" m'étais-je demandé. "Est-ce vraiment un investissement judicieux ?", "Et le trou de la couche d'ozone dans tout ça ?", "Est-ce que je prends du pain ce soir ?". Toutes ces questions se sont bousculées dans ma tête et j'avoue que j'avais alors décidé de seulement suivre de loin les tests des premiers acquéreurs. Il n'existait alors pas de distrib clé-en-main pour profiter pleinement de la mini-machine, et l'unique port USB ainsi que l'absence de port Ethernet sur le modèle A m'ont clairement refroidi. L'absence de réseau est pour moi rédhibitoire sur tout ordinateur digne de ce nom.

Puis le modèle B a été présenté. Plus cher (35$ soit 25€ HT environ), mais aussi plus complet et offrant enfin une connectivité intéressante avec son port Ethernet 10/100, même si toujours équipé à 256 Mo de RAM ce qui était souvent présenté comme juste par les testeurs. Alors un jour de désoeuvrement de juillet, j'ai dégainé ma carte bleue et j'ai passé commande sur le site de RS Components. Ayant étudié l'assembleur ARM à la fac, la perspective de quitter le confort du monde x86 ne m'a pas trop effrayée. Et puis l'ARM apparemment, c'est l'avenir, alors autant prendre de l'avance.

Comme la carte nue me semblait assez fragile, j'ai pris également un boîtier (transparent) et un adaptateur secteur (fournissant les 5V requis via la prise micro-USB).

Total final : 52,67€ TTC.

Bon, c'est évidement un peu plus cher que prévu, mais cela reste finalement raisonnable pour un petit ordinateur. Je reçois l'e-mail de confirmation, et là petite déception : expédition prévue dans 19 semaines ! Ce qui correspondait au début du mois de décembre... Bah, ça me fera un petit cadeau de Noël (inattendu, car d'ici là j'aurai oublié !).

Got it!

Le temps passe, décembre arrive, et avec lui un e-mail de notification m'informant que mon colis a enfin été expédié. Youpi ! Entre temps j'avais appris que les modèles B expédiés seraient désormais équipés de 512 Mo de RAM au lieu des 256 initiaux, et ce sans modification de prix. Une très agréable surprise !

Je découvre enfin mi-décembre un colis siglé "RS" dans ma boîte aux lettres et ne peut m'empêcher de le déballer un matin avant de partir au boulot. Bien m'en a pris car j'avais oublié que je n'avais pas acheté de carte mémoire dans mon pack (le prix n'étant pas intéressant). J'ai donc profité de ma pause dans la journée pour acheter une carte SD SanDisk de 16 Go catégorie 10 (donc proposant des débits de 10 Mo/s en écriture, ce qui est indispensable quand on l'utilise comme stockage de masse principal). De retour le soir, j'avais tout le nécessaire pour commencer à utiliser la carte, y compris l'image de l'OS que j'allais "graver" sur la carte SD pour pouvoir booter : Arch Linux ARM bien entendu.

Installation et configuration d'Arch Linux

L"installation" est d'une simplicité enfantine, et pour cause : il s'agit simplement de copier l'image sur la carte SD avec dd (sous Linux). Évidemment, il faut une machine avec un lecteur de carte utilisable. Dans mon cas c'est mon portable qui a servi, n'ayant pas de lecteur sur mon PC fixe. Le système est alors pré-configuré et prêt à être booté. Arch Linux oblige, c'est systemd qui joue les chefs d'orchestre, ce qui est totalement transparent d'un point de vue utilisateur évidemment. Au passage, la copie a tourné à 12 Mo/s en moyenne, la catégorie 10 de la carte n'est donc pas usurpée (mais bien sûr, la copie "brute" est peu représentative des performances observée une fois la carte formatée). J'insère la carte SD dans l'unique port du Raspberry Pi, puis je branche l'alimentation mcro-USB et les LEDs s'animent instantanément. Dix secondes plus tard elles se stabilisent : le système a terminé de booter !

Comme je n'ai pas connecté d'écran (aucun écran DVI de libre, pas d'adaptateur HDMI-DVI de toute façon, et aucune télé chez moi) c'est avec SSH que je dois contrôler ma mini-carte. La connexion est immédiate, l'accès root est ouvert avec le mot de passe — ultra-sécurisé — "root" :)

Je me retrouve alors dans un environnement totalement connu, et la différence d'architecture est entièrement transparente : on est sur un système GNU/Linux, point final. Seul le nom du kernel trahit que nous sommes sur une plateforme ARM :

[root@alarmpi ~]$ uname -a
Linux alarmpi 3.2.27-17-ARCH+ #1 PREEMPT Thu Dec 6 17:29:12 UTC 2012 armv6l GNU/Linux

L'image étant prévue pour tenir sur des cartes mémoires de capacités inférieures à la mienne, le partitionnement est adapté en conséquence : on a une partition /boot de 100 Mo formatée en vfat et une partition / d'environ 2 Go formatée en ext4. Pourquoi avoir choisi ext4 pour une partition destinée à être utilisée sur une carte SD ? Je ne l'explique pas. Mais qu'importe, je ferai avec. De toute façon ce partitionnement n'est pas adapté à ma carte. J'éteins donc mon RPi et rebranche la carte sur mon portable. Un petit coup de GParted et j'adapte la taille de / : 3 Go devraient être suffisants. Les 11,8 Go restants — inutilisés jusque-là — serviront pour la partition /home que j'en profite pour créer (en ext2 celle-là).

Après quelques dizaines de minutes, GParted m'annonce la fin de la procédure. Je reboote mon RPi à nouveau et adapte /etc/fstab afin que /home pointe bien sur la nouvelle partition /dev/mmcblk0p3. Un petit

$ mount -a

pour appliquer la modification et tout fonctionne comme attendu.

Ah tiens, mais je remarque que seuls 256 Mo de RAM sont disponibles d'après htop. Hum, étrange. Renseignements pris, il suffit de mettre à jour les paquets avec un classique

$ pacman -Syu

pour qu'au prochain reboot les 512 Mo soient utilisables. Là c'est bon je peux maintenant passer à la suite : ajout d'un utilisateur non-privilégié (nanawel), installation des utilitaires de base et configuration de tout ça.

La plupart de ces étapes et d'autres encore sont, comme souvent avec Arch Linux, expliquées de manière très concise mais efficace sur le wiki : https://wiki.archlinux.org/index.php/Raspberry_Pi

Maintenant se pose la question fatidique, celle évitée soigneusement jusque-là. Car c'est bien joli de tout bien configurer, tout préparer aux petits oignons et d'avoir un ordinateur de plus qui tourne sur son réseau... mais pour faire quoi ?

Une framboise voyeuse

J'avais détaillé il y a maintenant plusieurs mois comment j'avais monté un système simple de vidéo-surveillance au moyen d'une webcam USB (Logitech C510), d'un logiciel sous Windows (Yawcam) et de montages réseaux Samba couplés à du mirroring rsync. Malgré ses qualités (dont la plus importante : ça "juste marche"), et le fait qu'il fonctionne sans interruption depuis lors, cette installation possède néanmoins un défaut important : elle nécessite en effet un PC sous Windows qui tourne 24/24.

En plus de ça, Yawcam, bien que "plutôt léger", consomme facilement 100 à 150 Mo de RAM ainsi que des ressources de CPU. Enfin, dans mon cas où le dossier de réception est situé sur Usul (via montage Samba), il est nécessaire que celui-ci soit monté avant de lancer Yawcam, ce qui complique très fortement toute reprise automatique suite à une coupure électrique par exemple.

Mon Raspberry Pi configuré pourrait-il me servir à remplacer ce montage un peu bancal et rendre le système de vidéo-surveillance totalement indépendant ?

Une petite recherche sur la Toile et je tombe rapidement sur de nombreux articles présentant comment faire. Je me suis principalement inspiré de celui-ci : http://chris.gg/2012/07/using-a-ps3-eyetoy-with-the-raspberry-pi/ qui décrit pour ce faire comment utiliser Motion. J'ai ensuite largement débordé de ce cadre, d'où cet article.

Ce logiciel (libre) propose tout le nécessaire pour faire du streaming de webcam en temps réel (via HTTP), des snapshots réguliers, de la détection de mouvement entraînant au choix une ou plusieurs captures statiques (images) ou dynamiques (vidéos, grâce à ffmpeg). Il est également possible de contrôler la webcam si celle-ci est motorisée, et de la programmer pour qu'elle suive les mouvements détectés. Tout cela avec le support des webcams multiples, de MySQL et Postgres... et j'en passe (voir le wiki pour la liste exhaustive des fonctionnalités). Il est simplement difficile de demander mieux !

  Ni une ni deux, je me lance dans l'installation et la configuration de Motion, et son intégration à mon système déjà existant (car je vais conserver le dépôt sur mon serveur Usul). Ah oui, et ma machine s'appellera désormais "comeye" ("oeil com" dans la traduction française des Dune).

Installation de Motion et Samba  

Ici, que du classique :

$ pacman -S motion samba

Je ne détaillerai pas la configuration de Samba, le wiki d'Arch Linux (entre autres) est très bien fait pour cela. Il s'agit simplement ici de me permettre d'accéder au répertoire de travail de l'utilisateur UNIX nanawel depuis Windows (mon PC fixe étant encore sous XP).

On branche à présent la webcam sur un port USB libre du RPi et on observe les logs du kernel :

Dec 14 19:31:50 localhost kernel: [ 6572.038364] usb 1-1.3: new full-speed USB device number 8 using dwc_otg
Dec 14 19:31:50 localhost kernel: [ 6572.140566] usb 1-1.3: New USB device found, idVendor=046d, idProduct=0840
Dec 14 19:31:50 localhost kernel: [ 6572.140599] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Dec 14 19:31:50 localhost kernel: [ 6572.140619] usb 1-1.3: Product: Camera
Dec 14 19:31:50 localhost kernel: [ 6572.188841] Linux media interface: v0.10
Dec 14 19:31:50 localhost kernel: [ 6572.212764] Linux video capture interface: v2.00
Dec 14 19:31:50 localhost kernel: [ 6572.224080] gspca_main: v2.14.0 registered
Dec 14 19:31:50 localhost kernel: [ 6572.235084] gspca_main: STV06xx-2.14.0 probing 046d:0840
Dec 14 19:31:50 localhost kernel: [ 6572.237442] gspca_stv06xx: HDCS-1000/1100 sensor detected
Dec 14 19:31:50 localhost kernel: [ 6572.508397] input: STV06xx as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/input/input3
Dec 14 19:31:50 localhost kernel: [ 6572.512047] usbcore: registered new interface driver STV06xx

La caméra est bien détectée et semble utilisable directement. Pour s'en assurer, il suffit de lancer motion via la commande suivante (mode interactif) :

$ motion -n

Normalement la trace qui s'affiche sur le terminal devrait terminer avec :

...
[1] Using V4L2
[1] Resizing pre_capture buffer to 1 items
[1] Started stream webcam server in port 8081

Logiquement, on pourrait naviguer vers l'adresse IP du Raspberry Pi, sur le port mentionné et obtenir l'affichage de la webcam. Mais la configuration par défaut n'autorise que les accès depuis localhost. Comme je suis en headless je n'ai pas de navigateur utilisable sur le RPi pour le vérifier, nous verrons donc cela plus tard. Appuyer sur Ctrl-C pour stopper l'exécution dans le terminal.

  Configuration du daemon de Motion  

  Le daemon de Motion n'est pas activé par défaut. Pour remédier à cela :

$ systemctl enable motion

Mais si nous conservons le fonctionnement par défaut, cela signifie qu'il tournera en tant que root. De manière générale c'est une très mauvaise pratique, surtout pour un programme qui va être accessible depuis le réseau (et à terme, d'Internet). Je vais donc créer un utilisateur dédié motion dont le répertoire de travail servira de dépôt pour les images issues des détections de mouvements : /home/motion.

Je prends même un peu d'avance et crée un groupe homonyme qui permettra de faciliter la gestion des permissions sur les futurs fichiers.

$ groupadd motion
$ useradd motion -g motion -m -s /bin/false

Le groupe principal de l'utilisateur motion est donc aussi motion. Je crée un dossier /home/motion/detections qui recueillera les détections de mouvement :

$ su -s /bin/bash -l motion -c "mkdir /home/motion/detections"

(ici je me sers de su pour créer le dossier; comme l'utilisateur n'a pas de shell associé, je dois le préciser avec "-s")

Il s'agit maintenant de dire à systemd de lancer motion (le programme) en tant que motion (l'utilisateur) :

$ nano /usr/lib/systemd/system/motion.service
___
[Unit]
Description=Motion daemon
After=local-fs.target remote-fs.target
 
[Service]
User=motion                            # Ajouter cette ligne
ExecStart=/usr/bin/motion
Type=forking
#StandardOutput=null
StandardError=null
 
[Install]
WantedBy=multi-user.target

  Configuration de Motion  

  On passe ensuite à la configuration plus fine de Motion via le fichier /etc/motion/motion.conf (je ne présente que les lignes que j'ai modifiées par rapport aux valeurs par défaut) :

width 640
height 480
threshold 10000
quality 90
ffmpeg_cap_new off
target_dir /home/motion/detections
jpeg_filename %Y-%m-%d_%H-%M-%S-%q
webcam_motion on
webcam_localhost off

Explications :

• On augmente tout d'abord la résolution de la webcam à 640x480 (au lieu des 320x240 par défaut). J'ai essayé de monter plus haut mais au-dessus de cette valeur Motion perd la connexion avec la webcam, alors que celle-ci le supporte en théorie (il s'agit peut-être d'un problème d'alimentation, les ports USB ne pouvant pas fournir le courant requis par l'équipement). Je n'ai pas poussé plus loin mes investigations.  

MISE À JOUR 08/01/2013 : il se pourrait également que cela soit dû à une saturation du bus USB qui est extrêmement réduit sur la plateforme (et partagé avec le réseau !).

• Suite à l'augmentation de la résolution, on passe la sensibilité à 10000 au lieu de 1500 par défaut. Cela signifie qu'un mouvement sera détecté uniquement à partir du moment où 10000 pixels au moins seront différents entre deux captures consécutives par le logiciel (il y a par défaut 2 captures par secondes, mais c'est paramétrable). Cette valeur a été déterminée de manière empirique et correspond à mon besoin précis.
• On préfère conserver une qualité de JPEG de 90% (au lieu de 75% par défaut).
• On désactive la génération de vidéos suite à la détection de mouvement (car la place occupée par celles-ci est trop importante).
• On précise que les images comportant des détections de mouvement seront placées dans /home/motion/detections
• Les noms des fichiers seront de la forme "2012-12-14_17-45-23-01.jpg" afin de faciliter leur traitement par tri (http://www.lavrsen.dk/foswiki/bin/view/Motion/AdvancedFilenames)
• On active la détection de mouvement
• On autorise l'accès à la page de streaming depuis toutes les interfaces réseau (et non plus seulement localhost)

À ce stade, tout est prêt pour faire les premiers tests. On lance donc le daemon motion :

$ systemctl start motion

  Et on peut enfin naviguer depuis un poste relié au réseau local sur la page de streaming de l'application : http://[adresse_ip_eth0]:8081/

Attention : le streaming est constitué d'un flot d'images JPEG (type MIME : multipart/x-mixed-replace). Tous les navigateurs ne gèrent pas correctement ce type de contenu, je privilégie donc Firefox ou Chromium pour le visualiser (rien d'original cela dit ^^). 

La détection de mouvement doit désormais enregistrer des images JPEG dans le dossier /home/motion/detections.

Synchronisation distante

Pour le moment, les images sont uniquement enregistrées en local, sur la carte SD donc. Cela fonctionne bien mais n'assure pas la sécurité des données attendues par un tel système. Il suffit de retirer la carte mémoire pour perdre toute les traces des détections de mouvement. Je vais donc reprendre mon script de synchronisation déjà utilisé entre Usul et Sihaya, pour l'appliquer entre ComEye et Usul.

Mais pour cela j'aurai besoin de  incrond (utilisant inotify), que j'installe très simplement avec :

$ pacman -S incrond

et dont j'active le daemon avec :

$ systemctl enable incrond

La synchronisation impose de préparer la réception des fichiers du côté d'Usul. Il me faudra un utilisateur dédié sur le serveur pour cela (nommé fort logiquement comeye). À présent que nous sommes sur le réseau local, SSH n'est pas indispensable pour encapsuler les données des fichiers transférés comme c'était le cas entre Usul et Sihaya. On peut donc utiliser le protocole rsync d'un bout à l'autre (sans chiffrage), ce qui allègera en plus l'opération.

Sur Usul

Sur le serveur, cela signifie donc effectuer les opérations suivantes :

• Ajout de l'utilisateur "comeye" et du groupe du même nom

$ useradd comeye

• Activation du daemon rsync (désactivé par défaut)

$ nano /etc/default/rsync

(passer la variable RSYNC_ENABLE à "true")

• Préparer le dépôt pour la synchronisation (nommé ici "motdet", entre les crochets)

$ nano /etc/rsyncd.conf
___
log file = /var/log/rsync.log
timeout = 300
 
[motdet]
comment = Motion Detections from ComEye
path = /home/comeye/webcam/motion_detection
read only = no
list = yes
uid = comeye
gid = comeye
list = yes
hosts allow = 127.0.0.0/8 192.168.1.0/24

On force ici l'utilisateur (uid) et le groupe (gid) des fichiers qui arriveront par rsync, et on autorise les accès en écriture depuis les adresses du réseau local (192.168.1.X).

• Démarrer le daemon

$ /etc/init.d/rsync start

À présent le daemon rsync écoute sur le port 873 et est prêt à recevoir les fichiers que nous lui présenterons.

Sur ComEye

Le script modifié pour ComEye est le suivant :

Voir contenu sur PasteBin

On remarquera la syntaxe spéciale pour le protocole rsync dans la définition du dossier de destination (forme hôte::dépôt) :

DEST=usul::motdet

  Je le place à la racine du répertoire de travail de Motion : /home/motion/rsync-motdet-now.sh (et si nécessaire j'ajoute les permissions nécessaires à l'exécution par le propriétaire : motion)

J'édite ensuite la table des événements observés par incrond pour l'utilisateur motion :

$ incrontab -u motion -e

et j'ajoute simplement la ligne suivante :

/home/motion/detections IN_CLOSE_WRITE /home/motion/rsync-motdet-now.sh $# $%

puis je sauve et je quitte (:wq sous vim)

Note : pour je-ne-sais quelle raison, je ne peux pas éditer la table grâce à la commande incrontab qui échoue avec un "File not found". Il reste possible de passer par un simple

$ nano /var/spool/incron/motion

pour l'éditer à la main si cela se produit...

Chaque fichier écrit dans le répertoire /home/motion/detections déclenchera automatiquement l'exécution de la command /home/motion/rsync-motdet-now.sh. Par rapport à la configuration sur Usul (voir article correspondant) j'ai retiré IN_DELETE car je ne souhaite pas que la suppression des fichiers entraîne la synchronisation, comme le précise également la ligne :

RSYNC_CMD="rsync -av $ARGS $SRC $DEST"

dans le script de synchronisation (pas de "--delete-after" dans la ligne de commande).

La suppression des fichiers sur ComEye sera réglée par un job CRON quotidien (ici à 3h55), indépendant de celui en place sur Usul :

$ crontab -u motion -e
___
55 3 * * * find /home/motion/detections/ -type f -mtime +1 -name "*.jpg" -delete   #Delete motion detections older than 1 day

Ce point est crucial car sinon nous allons rapidement nous retrouver avec des dizaines de milliers de fichiers dans le dossier /home/motion/detections qui rempliront la partition, ce qui entraînera à terme des erreurs d'écriture.

Faisons un point...

Je récapitule le fonctionnement jusqu'ici :

1. La détection de mouvement entraîne l'enregistrement des photos correspondantes dans le dossier /home/motion/detections sur la carte SD de ComEye (mon Raspberry Pi)
2. L'écriture de fichiers dans ce dossier déclenche un événement incron qui va exécuter le script /home/motion/rsync-motdet-now.sh
3. Ce script va synchroniser les fichiers du dossier de ComEye vers le dépôt préparé sur Usul. La synchronisation ne concerne que l'envoi de nouveaux fichiers (les fichiers supprimés sont conservés intacts sur Usul).
4. Le dépôt sur Usul est lui-même surveillé par un job incron qui va envoyer les nouveaux fichiers vers Sihaya
5. Un job CRON quotidien va supprimer les photos datant de plus d'un jour dans le répertoire /home/motion/detections sur ComEye.

Ce système offre donc les garanties suivantes :

• La détection de mouvement est indépendante de toute autre machine que le RPi lui-même.
• Le RPi boote en une dizaine de secondes, et démarre automatiquement le daemon motion.
• Les photos issues de la détection de mouvement sont stockées en local sur ComEye PUIS envoyées sur le serveur Usul si celui-ci est est actif, ce qui duplique les données et protège ainsi de leur perte (accidentelle ou autre).
• En plus de cela, le dépôt sur Usul est le dossier qui est également synchronisé avec Sihaya, mon autre serveur. J'ai donc une duplication supplémentaire sur une machine distante (hors réseau local). À être parano, autant y aller carrément !

Inconvénients :

• D'après le script, la synchronisation (ComEye/Usul) ne s'opère à partir d'une écriture de fichier qu'après un lap de temps d'une seconde sans écriture. Si les mouvements sont continus, la synchronisation sera constamment retardée car de nouveaux fichiers seront écrits les uns à la suite des autres sans interruption, ne laissant pas la pause d'une seconde nécessaire pour déclencher la synchronisation. C'est un point que je tâcherai de traiter plus tard.
• La duplication des fichiers vers Sihaya impose au préalable que ceux-ci aient été copiés sur Usul, et donc que celui-ci soit actif. Il serait préférable que la synchronisation soit effectuée directement de ComEye vers Sihaya, sans utiliser Usul comme intermédiaire.

Et la surveillance dans tout ça ?

Bien que la détection de mouvement soit un point essentiel du système car il évite la présence permanente d'un "opérateur" qui surveillerait l'image, elle n'en demeure pas moins une des multiples fonctionnalités souhaitées (dont certaines sont déjà offertes par Motion). J'apprécie en effet de pouvoir à loisir jeter un oeil à l'image renvoyée par ma webcam régulièrement, et ce de n'importe où grâce à mon smartphone par exemple (Nexus S, sous Android bien sûr).

Petite liste des fonctionnalités qu'il me reste à mettre en place :

Authentification

Pour conserver l'aspect confidentiel de ces données il est indispensable d'en protéger l'accès, par un couple login/mot de passe par exemple. Or, s'il est bien possible d'affecter un couple de ce type à l'interface de contrôle accessible par HTTP (sur le port 8080), rien n'est prévu de base pour faire de même sur la page de streaming de l'image (sur le port 8081).

Chiffrement

Qui dit mot de passe, dit chiffrement nécessaire, car on ne va pas faire circuler un mot de passe en clair sur le Web, c'est évident. Mais là non plus rien n'est prévu par Motion en standard.

Capture JPG

Comme le protocole de streaming proposé par Motion (à base de multipart/x-mixed-replace comme je l'ai mentionné précédemment) est moyennement supporté par les navigateurs, surtout mobiles, et réclame une bande passante importante souvent insuffisante sur les réseaux mobiles, il est intéressant de pouvoir générer une image statique, un instantané issu du flux généré par Motion et qui sera accessible par une URL dédiée.

Accès direct à la dernière détection

De la même manière, il est enfin intéressant de pouvoir accéder rapidement à la dernière capture issue de la détection de mouvement.

Les fonctionnalités que je viens de lister ne sont pas offertes par Motion, mais il est possible de les réaliser avec un serveur HTTP et quelques scripts très simples. Je reviendrai donc dans un prochain article sur la configuration à appliquer à lighttpd (plus léger qu'Apache et largement suffisant dans ce contexte) et sur les scripts PHP à utiliser pour remplir tous ces besoins.

J'étends ma parenthèse ouverte lors de la partie précédente et continue l'évaluation des performances de cette fameuse machine.

Si vous avez raté le début :

Les aventures d'un 486 DX2 au XXIème siècle (1ère partie)

Les aventures d'un 486 DX2 au XXIème siècle (2ème partie)

Les aventures d'un 486 DX2 au XXIème siècle (3ème partie)

Let's benchmark

Je ne pouvais pas en rester là, sans avoir de chiffres "objectifs" à me mettre sous la dent qui me permettraient d'évaluer la puissance de la bête, et tant qu'à faire, la comparer à d'autres plus récentes de mon cheptel personnel. Je me suis donc mis à la recherche d'un programme de benchmark pour GNU/Linux pour tester au minimum le CPU et la RAM. Et je suis tombé sur sysbench. Les premières tentatives de compilation de la dernière version sur ma Slackware 8.1 se sont soldées par des échecs : les versions des paquets gcc et libtool (entre autres) étant trop anciennes. C'est finalement la dernière version de la série 0.3.x (0.3.4) sortie en 2005 qui s'est laissée binairiser.

À toute fin utile, il me faut mentionner que j'ai dû désactiver les "warning as error" avec

export CFLAGS="-Wno-error"

avant de lancer

./configure --without-mysql

pour pouvoir compiler l'intégralité du paquet sans erreur.

Voici les 3 tests que j'ai effectués :

• Processeur :

sysbench --test=cpu --num-threads=2 --max-requests=2 --cpu-max-prime=1000000 run

Ce test lance deux threads en parallèle qui vont rechercher chacun les nombres premiers de 3 à 1 000 000 deux fois de suite. Le résultat obtenu sera le temps mis pour compléter cette tâche.

• RAM :

sysbench --test=memory --num-threads=24 --max-time=20 run

Ce test lance 24 threads qui vont écrire des données en RAM durant 20 secondes. Le temps obtenu sera le débit moyen en Mo/s.

• I/O :

sysbench --test=fileio --num-threads=2 --file-test-mode=rndrw --file-fsync-all --file-num=16 --file-total-size=100M prepare
sysbench --test=fileio --num-threads=2 --file-test-mode=rndrw --file-fsync-all --file-num=16 --file-total-size=100M run

Ce test lance deux threads qui vont chacun lire 62 Mo de données et écrire 94 Mo de données aléatoires dans 16 fichiers préalablement préparés (me demandez pas pourquoi 62 et 94 alors qu'il y a marqué "100M" en paramètre...). Un appel à fsync() est effectué après chaque écriture de manière à forcer l'écriture réelle sur le disque et ne pas fausser les performances avec les caches. C'est donc sensé donner une idée des performances générales d'I/O. Le résultat obtenu sera le temps mis pour compléter cette tâche.

Les résultats

Voici les résultats obtenus dans un joli tableau récapitulatif (cliquer sur l'image pour la visualiser en taille originale) :

Comme vous pouvez le constater, j'ai effectué ces mêmes tests avec trois autres machines dont j'ai déjà parlé sur ce blog :

• Warrick : une modeste machine de 2003 à base d'Athlon XP 1900+ @ 1,6Ghz et équipée de 1 Go de RAM. Elle me sert principalement pour bidouiller sans craindre de perdre des données. J'ai dessus deux disques SATA de 80 Go de récupération (dont un de portable, donc en 5400 rpm). Elle tourne sous Arch Linux 32 bit (kernel 3.6).
• Usul : mon petit serveur maison qui revient très souvent ici. Il est équipé d'un Athlon 230 @ 1,6GHz, de 2 Go de RAM et de 2 disques SATA en 7200 rpm. Il tourne sous Debian 6 "Squeeze" 64 bit (kernel 2.6.32).
• Freeseed : une machine de bureau typique de 2009, équipée d'un processeur Athlon II X2 245 @ 2,9GHz et de 4 Go de RAM. Les tests ont été effectués sous Arch Linux 64 bit (kernel 3.6). Elle jouera ici la référence "haute" de ce comparatif, même si sa config n'est plus toute jeune.

Les six premières colonnes contiennent les résultats obtenus par sysbench et sont formées de 3x2 colonnes : pour chaque test la colonne de gauche contient le résultat "brut" et celle de droite le résultat transformé pour être exploitable dans un comparatif (plus cette valeur est élevée et meilleures sont les performances). La référence pour chacun des tests est Usul à qui j'ai attribué un score de 100 (sur fond gris dans le tableau).

Je pense que les résultats sont un peu décevants de par leur fiabilité mais l'idée y est et je m'en contenterai. Détaillons un peu.

Processeur

On remarque aisément le gouffre que représente l'écart des générations entre Ancient et les trois autres machines. Le petit 486 est ici 40 fois plus lent que l'Atom de première génération, et plus de 400 fois plus lent que l'Athlon ! Pour exprimer cette idée d'une autre manière, nous pourrions dire qu'il faudrait 400 processeurs 486 DX2 tels que celui-là pour obtenir la puissance de calcul d'un seul Athlon (lui-même aujourd'hui incapable de rivaliser avec un des derniers Core i7). Et encore, c'est une simplification grossière car le test porte ici sur des calculs "simples" alors que chaque génération de processeur apporte son lot d'optimisations pour la réalisation de calculs complexes nécessaires par exemple au décodage de flux vidéo et audio en temps réel (plusieurs additions simultanées en un seul cycle d'horloge, plusieurs multiplications, combinaisons des deux, etc.), optimisations qui ne sont pas présentes sur les 486.

En outre, l'écart qui sépare d'un côté Freeseed (Athlon II X2) et de l'autre Usul (Atom) et Warrick (Athlon XP) est aussi explicable par le fait que le premier est un vrai dual-core alors que le second est un monocore avec HyperThreading, et le troisième un simple monocore. Comme deux instances du test sont lancées en parallèle, il est évident que le dual-core est ici à son avantage, étant capable d'exécuter réellement les deux threads en parallèle, et donc de diviser le temps de réalisation par deux (à fréquence égale).

RAM

Ici aussi les paliers sont bien visibles, mais au-delà de ça le chiffre frappant est quand même le débit de la mémoire sur cette vieille architecture : à peine plus de 3 Mo/s. Le moindre disque dur d'aujourd'hui même en 4200 rpm (si, ça existe encore) obtient des débits au moins 6 fois plus élevés ! On compare tout de même du mécanique à de l'électronique pure ! Le rapport avec Freeseed et son Athlon est cette fois-ci de plus de 330, et plus de 100 sur les autres machines plus modestes.

I/O

Ce test m'a posé quelques soucis au niveau de l'interprétation des résultats obtenus. D'une part, le rapport de 20 entre Ancient et Usul (et son disque dur récent en 7200 rpm) est réaliste. Le rapport de 2,5 avec les performances de Warrick est également explicable par le fait que le disque de Ancient n'est pas aussi vieux que le reste de la machine (un Seagate Medalist 4321 en 5400 rpm d'environ 1999) et que Warrick est équipé d'un disque dur de 2,5" en 5400 rpm ayant au moins 6 ans.

D'autre part, les résultats bruts obtenus par Freeseed semblent totalement aberrants au vu de la configuration de la machine et de son âge (valeurs en rouge dans le tableau). Je n'arrive pas à expliquer avec certitude leur origine mais leur reproductibilité est confirmée, et ce, depuis différents environnements (Ubuntu 10.04 32bit, Arch Linux 64bit, Suse Linux 64bit). En l'état je préfère donc les ignorer car ils ne sont nullement représentatifs des performances observées en utilisation réelle.

Conclusion

En considérant que les résultats de sysbench sont représentatifs des performances générales des machines testées (hypothèse de travail), on constate de nets écarts dans les générations des composants.

Le CPU est et a toujours été un élément central des PC et on observe bien une évolution drastique de ses capacités sur deux décennies : d'après les résultats bruts on peut parler d'une capacité de calcul accrue d'un facteur 500. En réalité, comme je l'ai mentionné précédemment, le crible des nombres premiers met en jeu des calculs simples que seule l'augmentation de fréquence peut accélérer (et le multi-coeur, si plusieurs threads sont lancés en parallèle). Mais les processeurs modernes possèdent de nombreuses capacités supplémentaires par rapport à ceux des années 90 qui ne sont pas exploitées par le test (caches supplémentaires et plus larges, pipelining, circuits dédiés pour certains calculs, etc.). L'augmentation de la puissance finale est donc certainement largement supérieure à celle observée ici.

La mémoire suit la même courbe et se rapproche fortement des évolutions de performances des processeurs associés. Le débit aujourd'hui ridicule de 3 Mo/s (soit tout de même 24 millions de bits par seconde) obtenu sur Ancient était certainement impressionant lorsque les disquettes de 3,5" plafonnaient à 45 Ko/s en écriture (soit 66 fois plus lentement, avec 360 000 bits par seconde). Mis en perspective avec le débit des RAM récentes comme celle présente sur Freeseed, qui dépasse le Go/s (soit plus de 8 milliards de bits par seconde, un chiffre difficile à appréhender), on saisit mieux l'évolution gigantesque accomplie dans le domaine en 20 ans.

On termine avec les performances d'I/O (entrées/sorties pour les anglophobes), qui progressent plus modéremment par rapport aux deux autres valeurs, ce qui prouve encore une fois – et cela n'étonnera personne – que le stockage mécanique n'est clairement plus capable de suivre le rythme des composants purement électroniques. L'arrivée des SSD il y a maintenant quelques années est donc une évolution logique pour rattraper le retard pris par les périphériques de stockage durant plus de 10 ans. Mais on ne retirera pas si facilement aux bons vieux disques leur plus grande qualité : le coût au Go qui, malgré les colères de mère Nature, poursuit sa chute inexorable depuis plus de 50 ans.

Il est enfin important de préciser que l'OS n'est pas non plus pour rien dans les résultats et que le fait d'utiliser des kernels différents peut également avoir une influence non négligeable sur les indices de performance obtenus. Il fallait quand même le signaler.

À l'origine des bits : les électrons

Qu'en est-il à présent de la consommation électrique ? C'est la question finale que je me suis posée et à laquelle j'ai répondu grâce à mon Conserve Insight de Belkin (présenté il y a quelques temps ici-même).

Rien de très étonnant pour moi dans les résultats, cela correspond bien à mes expectations : 24W en idle et 28W en charge (par pics durant le boot). On était encore au temps où le moniteur (cathodique, seule religion ayant cours à l'époque) consommait plus que la tour elle-même.

Ces chiffres sont évidemment très bas par comparaison à ce que l'on peut obtenir d'un PC "moyen" actuel (il a été, un jour, un PC "moyen"). Je ne retrouve des chiffres similaires qu'avec mon serveur Sihaya tournant sur un Atom D510, et dont la faible consommation est un des objectifs d'Intel sur cette famille de processeurs.

Faisons à présent le rapport consommation/performances avec les chiffres obtenus pour déterminer l'efficacité énergétique de chacune des configurations.

La première colonne reporte juste les résultats obtenus plus haut. La seconde colonne contient les puissances maximales observées sur chacune des machines (lors d'un test séparé). Il faut lire la dernière colonne comme ceci : "Combien faut-il de Watts pour obtenir un point sysbench ?". Le score le plus faible est évidemment le meilleur, celui qui détermine quelle machine utilise le courant consommé le plus efficacement.

Sans appel, Freeseed remporte le combat haut la main, étant plus de 50 fois plus efficace qu'Ancient. Usul est second, quand même deux fois moins efficace que le vainqueur. Son score brut est néanmoins très correct et est bien représentatif de sa génération. Warrick accuse son âge et obtient la troisième place. Ancient finit bon dernier avec une efficacité exécrable mais également représentative de sa génération.

Attention : dans un ordinateur, surtout âgé, il ne faut pas négliger l'influence de la qualité de l'alimentation sur le courant absorbé. Comme je l'avais mentionné dans un article précédent, l'alimentation de Warrick par exemple est une sombre bouse qui consomme déjà 5W machine éteinte. Il est alors plus que probable que son efficacité en charge n'atteigne même pas 70%. Une partie importante du courant part alors tout simplement... dans la nature. Ou plutôt dans mon appartement, sous forme de chaleur inutile (sauf l'hiver), et n'a aucun rapport avec la consommation des composants de la machine. Les résultats sont donc là-aussi à prendre avec des pinces à barbecue tant les biais peuvent être importants.

Je ferme ici ma gigantesque parenthèse qui consistait à évaluer les performances de ma vénérable machine et à les comparer à ses petites-cousines, et je reprendrai le récit de mes péripéties, de l'installation d'un serveur X et d'une souris... Toute une histoire.

On reprend où l'on s'était arrêté : l'installation de la Slackware proprement dite. Mais je vais me permettre quelques digressions sur l'aspect hardware avant de revenir vers le soft un peu plus tard.

Je tiens quand même à rappeler que les événements que j'ai retracés (en les condensant en plus !) dans les deux derniers articles ont quand même pris 3 semaines. Entre le temps de faire les premiers tests, de commander la RAM supplémentaire et de la recevoir, de poursuivre les différents essais entrecoupés de (trop) nombreux reboots fastidieux m'imposant presque à chaque fois de reconfigurer le BIOS – notamment redétecter le disque –, et les recherches infructueuses sur la Toile, ce fût un travail de longue haleine.

Le fait de devoir reconfigurer le BIOS après chaque extinction (car manque de prises oblige, je débranchais la bête après utilisation) était particulièrement pénible. Surtout le premier boot où par défaut la RAM est vérifiée intégralement. Quand je n'avais que 6 Mo c'était déjà long, mais avec 16 Mo c'est devenu intenable, surtout le buzzer sadique qui égrène les Ko presqu'un par un.

Le remplacement de la pile CMOS

Possédant la pile d'origine, je me suis dit qu'il serait facile de trouver une remplaçante sur n'importe quelle boutique en ligne. J'ai rapidement regardé les inscriptions dessus et j'ai vu "3.6V", j'ai donc lancé mes recherches avec cette seule valeur, pensant qu'il était plus simple de chercher une pile de même tension plutôt que de même modèle. Mal m'en a pris.

Si j'avais lu correctement et complètement j'aurais également vu "1/2AA", ce qui m'aurait permis de trouver directement cette référence sur Amazon. Au lieu de ça j'ai écumé plusieurs boutiques chinoises sur le Web (ainsi qu'Amazon mais qui ne m'a rien sorti de pertinent avec cette seule information) qui m'ont amenées à la conclusion que ce modèle n'existait plus.

Je me suis alors dit que je pouvais sûrement bidouiller un abaisseur de tension qui me permettrait d'utiliser n'importe quelle autre type de pile en remplacement. J'ai donc commandé des résistances pour faire un pont diviseur de tension avec une pile de 9V. Sauf qu'un montage pareil consomme déjà à vide ce qui fait que la pile ne tient pas plus de quelques jours (expérience à l'appui !).

Après une semaine de tests j'ai dû me résoudre à l'évidence : mon montage ne tenait clairement pas la route. Il faut bien faire des erreurs pour apprendre, diront certains. C'était en cours de techno il y a 15 ans que j'aurais dû les faire, préciserai-je. Mais bon, l'ensemble ne m'aura pas coûté plus de 8€. Pour le temps perdu par contre c'est une autre affaire.

En recherchant cette fois le modèle exact (TL-5151 de Tadiran) je tombe sur de nombreuses boutiques qui proposent enfin de quoi m'aider ! (http://www.google.fr/search?q=tl-5151) Mon choix se porte logiquement vers Amazon qui affiche une référence équivalente pour 6€ (http://www.amazon.fr/dp/B002Q4W8SU/). Commande passée, et reçue en un délai record (expédiée le jour-même, et reçue 2 jours plus tard si je me souviens).

La pile d'origine était soudée à 2 fils reliés au connecteur qui se branchait sur la carte mère. Je n'ai pas de fer à souder donc j'improvise les contacts avec du papier alu et du chatterton (l'ami des bricolos du dimanche). Un petit test et tout se passe bien, je peux enfin sauvegarder les réglages du BIOS et débrancher à loisir l'alimentation ! C'est dingue comme un petit détail comme ça fait toute la différence.

Je peux à présent me concentrer sur le coeur du problème. Évidemment, c'est un peu tard, car maintenant que le réseau fonctionne je n'ai plus à rebooter sans cesse (enfin, c'est vite dit).

Premier aperçu

La copie des paquets mettra 3 heures environ pour s'achever, sans aucune erreur il faut le préciser. Un reboot plus tard – sur le disque cette fois ! – et me voilà avec un beau prompt à l'écran. Je procède aux réglages d'usage : ajout d'un utilisateur non-privilégié, suppression des daemons inutiles, configuration du réseau, et pour pouvoir me balader un peu sur mes partages réseau je rajoute Samba.

Environ 10 Mo de RAM sont utilisés après le login, ce qui laisse... huh... 6 Mo pour tout le reste. Je pressens quand même que ça va swapper sec dès que je vais lancer un programme un peu gros (et à cette échelle, tout programme est gros).

La copie de fichiers via Samba tourne à environ 500 Ko/s ce qui balaie immédiatement d'un revers de la souris toute possibilité d'en faire un serveur de fichiers décent.

Les ralentissements observés lors du lancement de commandes semblent d'ailleurs surtout intervenir dès l'accès au disque. Un petit benchmark rapide devrait nous aider à y voir plus clair.

root@ancient:~# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads:   128 MB in  9.69 seconds = 13.21 MB/sec
Timing buffered disk reads:  64 MB in 42.96 seconds =  1.49 MB/sec

Une brève comparaison avec Usul, mon petit **home server** :

root@usul-server:~# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads:   1076 MB in  2.00 seconds = 537.50 MB/sec
Timing buffered disk reads: 280 MB in  3.01 seconds =  92.97 MB/sec

Argl. Ah oui on n'est clairement pas sur la même planête ! Pas étonnant que les tranferts de fichiers par le réseau soient si lents. Le disque est déjà à la ramasse pour fournir les données en lecture, alors on imagine à peine en écriture !

Mais parlons à présent CPU. Que nous disent tout d'abord les informations extraites de /proc/cpuinfo ?

root@ancient:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 4
model           : 3
model name      : 486 DX/2
stepping        : 5
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme
bogomips        : 33.17

Deux choses me sautent aux yeux ici : tout d'abord la ligne "bogomips" qui révèle la triste évidence : ce CPU est à des années-lumières de ce qui se fait aujourd'hui. Cette mesure, toute relative qu'elle est, est une évaluation de la puissance du processeur. Plus exactement, c'est le nombre de millions de fois par seconde qu'un processeur est capable de... ne rien faire. Oui c'est une boucle vide quoi. Ici en l'occurence il est très simple de calculer sa valeur : c'est la fréquence brute du processeur (en MHz) divisée par deux : 66 / 2 = 33 le compte est bon, tou-dou-dou.

Si je consulte la même valeur sur mon Atom 230 – un CPU qui est dans l'extrême limite basse de ce qui se faisait en 2008 – j'obtiens presque 100 fois plus :

bogomips        : 3191.94

Ici le calcul est inverse : architecture et HyperThreading aidant, c'est la fréquence brute du processeur multipliée par deux : 1600 x 2 = 3200, le compte est bon là aussi. C'est donc Michel qui remporte cette manche, et Maryse nous quitte mais repart avec l'Encyclopédie Larousse en 22 volumes. À la semaine prochaine. Heu non c'pas ça.

L'autre valeur qui est assez marquante également est "flags" qui liste toutes les extensions supportées par le processeur, permettant entre autres d'utiliser des registres supplémentaires par rapport au standard x86 ainsi que de réaliser des opérations complexes en une seule instruction. Ici nous n'avons que... deux extensions : 

• "fpu" : Floating Point Unit permettant d'accélérer grandement les opérations en virgule flottante (opérations sur des nombres réels),
• "vme" : Virtual-8086 Mode Enhancement permettant de simuler le mode réel du processeur original 8086 

Si je compare là encore avec mon simple et modeste petit Atom de 2008 la différence est abyssale :

...
flags                : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
...

Je ne vais pas détailler ici chacune d'elle, il est facile de trouver leur signification par Google. On retiendra cependant "mmx", célèbre pastille marketing d'Intel de la fin du XXème siècle, "lm" (long mode) qui signifie que le processeur est capable de fonctionner en mode 64bit, et "sse" qui fût la réponse d'Intel au 3DNow! d'AMD sorti en 1998, et dont les différentes évolutions ultérieures sont aussi présentes ("sse2" et "ssse3").

Ce sont toutes ces extensions qui font aussi la différence du point de vue des performances de ces deux processeur. Des programmes utilisant intelligemment leur support – ou ayant été compilés pour tirer parti de celle-ci – verront leur exécution largement accélérée (à fréquence égale j'entends).

Ces résultats parcellaires me poussent à lancer un benchmark plus important avant de poursuivre la configuration de ma Slackware, sur lequel je reviendrai très prochainement dans le prochain article (qui devrait arriver rapidement puisque déjà presque rédigé). Stay tuned :)

Merci American Dad, encore une fois.

J'ai raconté dans un article précédent que j'avais installé une webradio sur mon serveur Usul. J'ai utilisé pour cela MPD, d'abord en utilisant Icecast2 pour la diffusion, avant de me rendre compte que MPD proposait déjà un système simple (et économe en ressources !) pour assurer ce rôle. Pour rappel, cette radio est chargée avec une playlist composée de tous mes dossiers de musique hébergés sur mon NAS, et les joue aléatoirement.

MPD Playlist Updater

Comme ma musique évolue très régulièrement (suite à un tri de ma part, à l'ajout de nouveaux albums, ...), j'avais initialement un petit CRON nocturne qui était chargé de rafraîchir la playlist en reparcourant les dossiers. Mais au bout de quelques mois j'ai trouvé que certaines des pistes n'avaient rien à faire sur la radio : j'aurais bien aimé les exclure automatiquement à chaque rafraîchissement.

J'ai donc créé un petit script en PHP – appelé de manière très originale "MPD Playlist Updater" –  qui est chargé de regénérer la playlist puis de la filtrer. Ce script se repose sur mpc pour commander le rafraîchissement, puis parse ensuite le fichier m3u obtenu (situé sur Debian dans /var/lib/mpd/playlists) et supprime les lignes selon une méthode simple :

• un fichier exclude.conf est présent dans le répertoire du script mpd_playlist_updater.php et contient un filtre par ligne
• ce fichier est est lu par le script et chaque ligne est utilisée comme pattern du filtre
• si une entrée de la playlist matche un de ces patterns, alors elle est retirée de la playlist

L'ajout et la modification de filtre est donc très simple à effectuer puisqu'il suffit d'ouvrir le fichier exclude.conf avec un éditeur de texte (compatible UTF-8...).

Un petit résumé est écrit sur la sortie standard, ce qui entraîne l'envoi d'un mail lorsque le script est exécuté par CRON. Je peux ainsi savoir quel est le nombre de fichiers présents dans la playlist du jour et le nombre de fichiers exclus. Logiquement, le premier chiffre augmente régulièrement...

16384 et pas une de plus

Mais en regardant les rapports envoyés par mail, j'ai constaté récemment que le nombre de fichiers n'évoluait pas, alors même que je venais d'ajouter plusieurs albums à ma mp3thèque. Le nombre restait étrangement stable à 16384. Tiens donc.

Ce nombre me dit quelque chose. Voyons voir, ouvrons la calculatrice et faisons 16384 / 8. Résultat = 2048. Hum, d'accord à vue de nez à fait 2^14, ce n'est donc pas un nombre quelconque. Mais pourquoi le nombre de fichier reste-t-il bloqué à ce chiffre ?

Je parcours les dossiers de musique en utilisant

$ mpc ls

 et tout les dossiers apparaissent bien, y compris les tout derniers, ajoutés récemment. Je m'en remets alors à Google en espérant ne pas découvrir que je suis le seul à essayer de mettre plus de 16 384 titres dans ma playlist. La réponse m'apparaît au bout de quelques minutes : il existerait un paramètre max_playlist_length...

Je consulte donc /etc/mpd.conf et effectivement, un petit bloc tout en bas du fichier dénommé "Resource Limitations" contenant ce paramètre, avec comme valeur par défaut... 16384. Hop, passons-le immédiatement à 32768 (j'aime les nombres ronds).

Je relance mon MPD Playlist Updater et ô surprise : le nombre de fichiers présents dans la playlist est passé à plus 20 000 ! Ça alors...

Si jamais une des deux informations présentées ici peut être utile à quelqu'un (à savoir le petit script de filtrage et la limite de la taille de la playlist), you're welcome!