Born to be wired
749222 visites
Uptime 105 days

Articles taggés avec ‘linux’

 Bonne année, <insert_name_here> !

 18 janvier 2013  Domotique  5 commentaires
tbird-addess-book

Avertissement  : le contenu suivant est susceptible de heurter la sensibilité des personnes pourvues d’un minimum de sens moral.

Quand on est djeun’s, qu’on a plus de 500 amis sur tous ses réseaux sociaux confondus, et un forfait avec SMS illimités (ce qui aujourd’hui est à portée d’à peu près tout le monde, vu que ça coûte 0 euros chez Free), on est soumis à une rude problématique le soir de la Saint Sylvestre : comment ne pas perdre trop de temps à envoyer des SMS de bonne année à tous ses contacts, pour profiter au maximum de la soirée sans rester pendu à son mobile, tout en montrant ostensiblement et avec classe sa présence sur les réseaux sociaux ?

(suite…)

 SMS automatisé – Round one, fight !

 16 janvier 2013  Domotique  10 commentaires
Nokia 3310 avec carte SIM B&You et data cable

S’il existe une fonctionnalité que je souhaite mettre en place depuis bien longtemps autour de mon serveur sans me ruiner, c’est la possibilité de pouvoir envoyer de manière automatisée des SMS de notifications aux numéros de mon choix. Et accessoirement, de pouvoir en recevoir aussi.

Cela ouvre en effet un large éventail de possibilités supplémentaires : couplage avec le système domotique, diversification des moyens de notification, diversification des moyens de déclenchement d’actions, ou pourquoi pas moyens complémentaires de validation d’une session, comme le font la plupart des banques à l’heure actuelle lorsqu’un particulier demande une transaction d’une certaine importance.

Il y a quelques mois, ceci n’aurait été réalisable pour un montant raisonnable à faible volumétrie, lorsqu’on table comme moi sur une vingtaine de SMS par an à tout casser, qu’en passant par des API développées par des prestataires tiers, du type smsbox.net. Mais pour ma part, j’aime l’idée de garder le contrôle de mon architecture amateur sur le plus grand périmètre possible, et ce type de service facture une valeur ajoutée par rapport au coût du SMS simple que je souhaite pouvoir économiser. Avec l’arrivée l’an dernier de l’opérateur béni des dieux Free Mobile sur le marché, les opérateurs de téléphonie mobile ont tous subitement attrapé « comme par hasard » la fièvre humaniste/altruiste et ont décidé à la quasi-unanimité de revoir à la baisse leurs tarifs exorbitants. D’autres encore se sont diversifiés, à l’instar de B&You, proposant une carte pré-payée sans durée limite de validité, pour peu que le client s’affranchisse d’au moins un acte tarifé (communication, SMS, data…) par an.

C’est cette nouvelle offre qui m’a fait sauter le pas, à 5 centimes par an le coût d’envoi du SMS de ping permettant de maintenir la ligne, il serait dommage de se priver.

Avant d’investir dans du matériel plus évolué, j’ai tout d’abord cherché à réutiliser ce qui trainait dans mes vieilles affaires. Pour cette maquette, j’ai donc utilisé :

  • Un serveur Linux, dans mon cas un clone de ma Debian sur VM, qui fera office de machine d’émission de SMS.
  • Un téléphone quelconque avec une carte SIM valide, dans mon cas mon Nokia C7-00 (ne vous moquez pas S.V.P, je n’ai pas les moyens de claquer ma fortune dans un Galaxy S3), qui sera l’appareil destiné à la réception.
  • Un vieux Nokia 3310 de récup’, le téléphone star que les moins de vingt ans ne peuvent pas connaitre, qui faisait de vous à l’époque le personnage le plus hype des utilisateurs de mobile, car on pouvait jouer à Snake et composer ses propres sonneries (moi j’avais composé Ecuador de Sash! et pour ça j’inspirais le respect à mes semblables).
  • Une carte SIM B&You, 4.99€, réglée avec Eurocard Mastercard.
  • Un câble de communication 3310 USB, 5€ sur eBay, réglé avec Eurocard Mastercard.
  • Le plaisir de monter sa propre plate-forme d’envoi de SMS, ça n’a pas de prix.

Pour commencer, on insère la carte SIM B&You dans le mobile et on connecte le câble de communication sur celui-ci. Notez que comme il s’agit d’un modèle du début des années 2000, époque où les téléphones mobiles étaient relativement peu conçus pour permettre à leurs utilisateurs de les connecter avec du matériel informatique, il faut démonter la partie arrière de la coque pour pouvoir brancher le câble de comm’.

Nokia 3310 avec carte SIM B&You et data cable

Nokia 3310 avec carte SIM B&You et data cable

On branche ensuite l’autre extrémité du câble sur le port USB du serveur, la VM pour moi dans le cadre de cette maquette. On allume le mobile et on le déverrouille en entrant le code PIN. On en profite pour changer le logo par défaut, parce que ça permet de se la péter quand on poste la photo sur un blog de geek.

Le soft utilisé pour le logo : LogoManager sous Windows. Oui, ça ne sert à rien, et alors ?

Le soft utilisé pour le logo : LogoManager sous Windows. Oui, ça ne sert à rien, et alors ?

Le câble est basé sur un chip PL2303, qui est automatiquement reconnu par le système pour peu qu’on ait embarqué le support pl2303 dans le kernel ou en tant que module.

dhalsim:/$ lsusb
Bus 003 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Ensuite la magie opère grâce à gnokii, un soft en ligne de commande spécialisé dans la communication FBUS utilisée par les vieux Nokia, mais qui peut aussi communiquer en commandes AT comme le font la plupart des téléphones actuels. Le wiki de gnokki indique que le 3310 utilise le driver Nk6100, ce que j’indique dans le fichier de configuration en même temps que le device sur lequel le câble data USB est connecté. J’ai modifié uniquement 3 lignes du fichier de configuration par défaut :

[global]
model = 6110
port = /dev/ttyS0
connection = serial

On demande à gnokii d’envoyer un SMS de test, grâce à une commande simplissime. Par sécurité, j’ai indiqué le n° destination au format international. J’imagine que l’utilisation des n° au format national est possible aussi.

dhalsim-session-gnokii

On admire enfin la réception du SMS sur le mobile destinataire. On peut alors savourer la victoire avec un bon Dry Martini comme le ferait James Bond après une mission accomplie avec classe.

You win! Perfect!

You win! Perfect!

Voila, c’est tout simple ! J’ai fait une mini-vidéo du processus complet d’envoi-réception, dans laquelle j’envoie simplement la date et l’heure système par SMS, au lieu du message de test ci-dessus. C’est un peu flou, filmé et monté à l’arrache, et il a fallu compresser à outrance pour conserver un fichier de taille raisonnable, mais il faut savoir que je subis des pressions fortes d’une partie de mon entourage professionnel et en même temps unique lectorat pour que je mette en ligne l’article accompagné de la vidéo sans attendre les calendes grecques. Ces gens s’acharnent sur la touche F5 de leur clavier toutes les 10 secondes, me mettant par effet de bord sous la menace d’une attaque DDOS, je ne peux me permettre de ruiner leur productivité plus longtemps :)

Prochaine étape de ce projet : seconde maquette avec l’utilisation d’un « vrai » modem GSM et des commandes AT. À moins qu’une connerie ne vienne s’intercaler dans le programme…

 Pong Clock, le spin-off

 18 novembre 2009  Bricolage, Projet Arcade  5 commentaires
Pour un peu, on pourrait croire que je prône mon propre culte de la personnalité...

Angoissé par la peur de l’échec dans la reconversion du PC portable en horloge Pong, je cherchais depuis un moment des idées alternatives de recyclage, histoire de me replier sur un autre projet qui permettrait de sauver l’ordinosaure d’une lente agonie.

Jusqu’au jour où l’idée de génie fut apportée par Sylvain : un cadre photo numérique !

Aujourd’hui je peux dire que l’idée est pleinement exploitable sur ce type de machine. SVGAlib est fait pour ça. Mieux, le programme qui contenait les lib SVGA compilées pour DSL, nommé zgv, est, si vous vous rappelez du billet précédent, un visualiseur d’images ! Cerise sur le gâteau, il peut même afficher des diaporamas !

J’ai fait le test en 10 minutes : sur le portable, si je ne force pas un affichage en 320×240, mes images s’affichent, mais sont parfois décalées de quelques pixels sur la droite pour une raison inconnue. Éventuellement à tweaker légèrement en fonction du portable. Pour info, zgv a un pendant sous X11 nommé xzgv.

J’enregistre mes réglages sur DSL de la manière suivante (force la résolution, le nombre de couleurs, et les paramètres de zoom) :

alias zgv='/opt/zgv/zgv2 -p -j -z -m "320 240 8"'

Je peux ensuite lancer un diaporama avec la commande suivante :

zgv /path/to/my/pictures/*

Et voila, la preuve en image, un cadre photo numérique artisanal réalisé sans effort. :)

Pour un peu, on pourrait croire que je prône mon propre culte de la personnalité...

Pour un peu, on pourrait croire que je prône mon propre culte de la personnalité…

PS : pas de panique, pour le moment ma roadmap en ce qui concerne le laptop est toujours l’horloge Pong. ;)

 Le pixel infernal

 17 novembre 2009  Bricolage, Projet Arcade  3 commentaires
Mince, figlet me dit que je devrais aller me coucher !

Dans l’article précédent, je détaillais mes premières étapes de la transformation d’un vieil ordinateur portable en horloge Pong, à savoir l’installation d’un Damn Small Linux sur le système.

L’étape suivante n’est pas de tout repos, puisqu’il faut maintenant afficher à l’écran les graphismes de mon choix. En l’occurrence, un terrain, deux raquettes carrées, une balle carrée, et un score qui évolue en fonction de l’heure. Mais ne plaçons pas la charrue avant les bœufs, autant commencer doucement, et tenter d’afficher dans un premier temps un modeste pixel.

Car à ce stade, DSL démarre en mode console.

Elle est belle, ma console, elle est belle !

Elle est belle, ma console, elle est belle !

Après un peu de nettoyage dans les scripts de démarrage de DSL, j’obtiens beaucoup moins d’erreurs lors du boot. À terme, mon but est d’avoir un affichage le moins verbeux possible pendant le boot, histoire de donner à la future horloge un petit côté appliance. Comprenez par là que les messages affichés pendant la phase de démarrage sont totalement inutiles aux yeux des non-informaticiens, il sera donc intéressant d’en diminuer le nombre, tout en gardant la possibilité de les afficher moyennant la manipulation appropriée (un paramètre passé au noyau, par exemple). Mais ceci est purement cosmétique et ne constitue pas la priorité n°1.

Nous sommes donc en mode console. Le mode console, c’est une division de l’écran en 80 colonnes et 25 lignes, chaque case située à leur intersection pouvant afficher exactement un caractère, ni plus ni moins. C’est donc fait pour afficher du texte, de manière (quasi) exclusive.

Alors, grâce à des bidouilles comme figlet, déjà utilisé sur mon minitel, il est possible de dessiner avec les caractères de la console, mais on est très loin de maîtriser ce qui sera affiché au pixel près.

Mince, figlet me dit que je devrais aller me coucher !

Mince, figlet me dit que je devrais aller me coucher !

Alors, comment diable afficher un simple pixel sur l’écran ? Linux utilise généralement un serveur X11 pour tout ce qui touche au mode graphique. C’est sur X11 que vient se greffer le gestionnaire de fenêtres qui affiche à l’utilisateur un bureau ergonomique et coloré. Bien que le gestionnaire de fenêtres sur DSL soit extrêmement léger, le pauvre portable avec ses 8 Mo de RAM n’a pas les ressources suffisantes pour en profiter. J’ai quand même fait le test pour rigoler, je peux afficher un bureau (640×480, 16 couleurs) en moins de 3 minutes, le tout étant suivi par une interminable période de swap, pendant laquelle il est inutile d’espérer lancer la moindre commande. En définitive, on abandonne complètement l’idée.

Le bureau, c'est possible, à condition d'avoir le temps...

Le bureau, c’est possible, à condition d’avoir l’éternité devant soi…

Dans mon cas, le salut ne sera pas apporté par X11. Il me faut quelque chose de plus léger pour afficher mon pixel. Quelque chose qui me permette de programmer des applications graphiques sans passer par X11. Quelque chose comme SVGAlib.

Caution - Geek content

Attention, à partir d’ici, ça devient un poil plus technique. Le passage qui va suivre est susceptible de déclencher des nausées, voire des vomissements, chez les non-informaticiens. Je décline toute responsabilité.

SVGAlib est une bibliothèque graphique de bas niveau pour Linux. Tout à fait dans l’esprit de ce dont j’ai besoin. En plus, le site fourmille d’exemples. Je recopie le code permettant d’afficher un simple pixel à l’écran et le compile dans la foulée.

#include <stdlib.h>
#include <vga.h>

int main(void)
{
	vga_init();
	vga_setmode(G320x200x256); // Passe l'écran en résolution 320x200, 256 couleurs
	vga_setcolor(4); // On sélectionne la couleur rouge
	vga_drawpixel(10, 10); // On dessine le fameux pixel

	sleep(5); // On attend 5 secondes...
	vga_setmode(TEXT); // On repasse en mode console

	return EXIT_SUCCESS; // Et on sort fièrement dans la bonne humeur
}

À ce stade, transférer le programme compilé pour le tester sur le portable est une activité relativement chronophage. Rappelez-vous : pas de lecteur CD, pas de carte réseau.

Je décide donc d’installer une copie de DSL dans une machine virtuelle (qui elle est équipée d’une carte réseau virtuelle) et sur laquelle je peux transférer mes versions compilées à grands coups de netcat.

Bien que la compilation (en environnement Debian) se passe sans trop de problèmes bloquants, la première exécution du programme dans la machine virtuelle ne se termine pas par un franc succès. Les libs SVGA sont absentes par défaut dans DSL. Qui pourrait en faire un reproche, s’agissant d’une distrib allégée ?

À tout hasard, je choisis de copier les libs de ma Debian dans DSL. Cette solution barbare fait lamentablement planter le programme avec pour toute sortie la célèbre Segmentation Fault. Je ne saurais pas expliquer exactement pourquoi, il existe de nombreuses raisons pour que cette opération ne fonctionne pas. Les libs ne sont pas optimisées pour 486, elles ne sont pas compilées pour fonctionner sur un noyau 2.4, elles sont compilées avec des options propres à Debian, etc… Un coup dans l’eau.

À cet instant, je suis confronté au moment d’angoisse que tout développeur a connu, quand il sait que toutes les solutions simples n’ont pas fonctionné, et qu’il va falloir sortir l’artillerie lourde sans savoir dans quelle direction tirer. J’en profite pour remercier tipeon, qui a toujours de bonnes idées lorsque je lance des appels à l’aide à la cantonade sur les forums ;)

Je commence à envisager de cross-compiler ces libs moi-même, quand, au détour d’une recherche sur le net, entre deux sites pornographiques, je découvre sur cette page un visualiseur d’images utilisant SVGAlib et porté sur DSL : ZGV. Les libs étant comprises dans l’archive, je les déploie sur ma machine virtuelle, relance mon programme, et constate avec le plus grand bonheur un écran vierge, à l’exception d’un petit pixel rouge en haut à gauche de l’écran. Bingo ! :)

C’est un petit pixel pour le geek, mais un bitmap géant pour la communauté.

À partir de ce moment, le concept est démontré, il est donc possible d’utiliser SVGAlib pour afficher de manière instantanée à peu près n’importe quel graphisme sur commande à partir de la console. La preuve avec ce second exemple qui sera plus parlant qu’un bête pixel rouge :

Un joli dégradé de bleu, merci SVGAlib !

Un joli dégradé de bleu, merci SVGAlib !

Voila qui termine la partie qui à mon sens pouvait poser le plus de difficultés. Le reste, bien que pas forcément évident au premier abord, pourra se résumer à un peu de programmation et un peu de bon sens. Mais je ne manquerai pas de le détailler.

À bientôt pour la suite des aventures du laptop qui ne voulait pas mourir ;)

 Le recyclage, c’est l’avenir

 17 novembre 2009  Bricolage, Projet Arcade  2 commentaires
Windows 3.1, un OS que les moins de vingt ans ne peuvent pas connaître...

Ce week-end, j’ai eu l’occasion de concrétiser quelque chose qui me tenait à cœur depuis longtemps : passer une nuit torride avec Gemma Atkinson donner une seconde vie à un ordinateur portable cacochyme. Chacun ses fantasmes, l’un n’empêche pas l’autre.

Cela fait effectivement un long moment que je guette l’opportunité de transformer une antiquité informatique en horloge Pong, objet de décoration post-vintage affichant le sommet de la geekitude. Oui, le mot existe, en tous cas selon Google.

J’ai donc retroussé mes manches et inspecté le matériel à ma disposition : deux portables Compaq Contura. Des ordinosaures portables en puissance, équipés d’un processeur 486 cadencé à 33 MHz, de 8 Mo de RAM, et respectivement 250 et 350 Mo de disque dur. En d’autres termes, n’importe quel téléphone mobile d’aujourd’hui affichera plus de puissance de calcul. Je remercie au passage Kiwi et HKI pour m’avoir permis de disséquer les deux bécanes.

Après un premier état des lieux, un des laptops boote sur un magnifique bureau Windows 3.1, le second ne daigne pas démarrer. Les batteries ainsi que les piles au lithium sont mortes dans les deux cas.

Windows 3.1, un OS que les moins de vingt ans ne peuvent pas connaître...

Windows 3.1, un OS que les moins de vingt ans ne peuvent pas connaître...

Suite à ce constat, je décide de mettre le portable inerte de côté, en conservant toutefois son disque dur qui servira de base pour les opérations. Foutu pour foutu, autant flinguer ce disque là avec mes expérimentations en premier.

Depuis le temps que je réfléchis à ce projet, j’ai dans l’idée qu’il me faut un OS minuscule mais efficace. Traduisez : un Linux. Je me tourne assez rapidement vers Damn Small Linux (DSL), une distrib dont la taille du Live CD ne dépasse pas 50 Mo, optimisée pour occuper une place réduite en mémoire et tourner ainsi sur les plus petites configs.

Ma décision est prise rapidement, exit DOS/Windows 3.1 et place à un système d’exploitation digne de ce nom.

Un premier problème se présente toutefois rapidement : comment installer un système d’exploitation de 50 Mo sur une machine qui n’a ni lecteur CD, ni carte réseau ? Examinons les possibilités :

  • Le diviser en 35 disquettes de 1.44 Mo, booter sur la première disquette, passer 2 heures à lire chaque disquette une par une et tout recommencer lorsque l’opération foire à la 34ème. Non, ça sent le vécu, très peu pour moi.
  • Transférer le contenu du CD par câble série. À 9600 bps, je peux avoir mes données en 12 heures en comptant uniquement le payload. Mieux vaut oublier. En plus il faudrait d’abord booter sur un Linux qui piloterait le port série, une sorte de concept de la poule et le l’œuf réactualisé. Mieux vaut trouver une méthode qui évite les migraines.
  • Démonter le disque dur, le brancher dans une carcasse de PC desktop équipé d’un lecteur CD et au besoin d’une carte réseau, et lancer l’installation à partir de ce poste. Voila une solution jouable.
Le disque dur et son adaptateur, prêt à être connecté

Le disque dur et son adaptateur, prêt à être connecté

En fouillant dans mes pièces détachées, je retrouve une nappe IDE 3.5″ vers 2.5″ qui m’a été généreusement donné par karamilo, que je remercie. Sans cet adaptateur, impossible d’aller plus loin.

Je branche donc le disque dans une des carcasses de PC qui squattent mon séjour. La poisse fait son œuvre : je flingue une alim silencieuse récente pendant l’opération. :(

Montage temporaire pour l'installation de DSL

Montage temporaire pour l'installation de DSL

Heureusement, ce ne sont pas les alims qui manquent dans mon capharnaüm. Après remplacement, le PC desktop peut booter sur le CD d’installation de DSL. L’installation est effectuée en quelques minutes.

Vient enfin le moment de vérité : le portable va-t-il démarrer correctement DSL une fois le disque dur reconnecté ? Avec Windows, en général, rien n’est moins sûr. Avec Linux, en général, c’est du gâteau, pour peu qu’on ait un noyau générique et des périphériques pas trop hors normes. Cette fois-ci ne fait exception à la règle. :)

Damn Small Linux en plein processus de démarrage

Damn Small Linux en plein processus de démarrage

La première étape est donc terminée : le vieillissant portable et son non moins vieillissant Windows 3.1 font peau neuve avec un Damn Small Linux qui me servira de base pour afficher l’horloge Pong si chère à mes rêves.

Mais cela, nous le verrons un autre jour. Stay tuned…

PS : je m’excuse pour la piètre qualité des photos et promets d’investir dans un appareil numérique digne de ce nom très bientôt.

 Server Academy :: Les perfs

 1 octobre 2009  Projet Serveur  Aucun commentaire
test1

Server Academy

Il est temps de regarder plus précisément ce que nos candidats ont dans le buffet !

Pour cela, je leur ai fait passer une série de 8 tests de performances brutes. Ces tests ne sont pas toujours pleinement représentatifs de la charge réelle supportée par un serveur, mais ils sollicitent de nombreuses parties de l’architecture matérielle (principalement processeur, RAM, contrôleurs disques et disques eux-mêmes).

Il convient toutefois d’établir dans quelles conditions ces résultats ont étés obtenus. Tous les serveurs sont en Debian 5 et ont bénéficié d’une fresh intall, à l’exception de Ryu qui a tourné sur son installation existante. Voici le détail des conditions de tests au cas par cas :

  • RYU : continuité de service oblige, Ryu a passé ces tests tout en continuant à effectuer ses tâches quotidiennes (principalement servir des pages web, relayer des requêtes DNS, et teergruber des spammeurs). Ses performances relevées sont donc légèrement sous-évaluées par rapport aux autres candidats qui étaient idle lors des tests.
  • GUILE : rien de particulier à signaler.
  • ZANGIEF : les pré-tests ont montré des problèmes de performances importants au niveau des accès disques, à fortiori en RAID5. Afin de minimiser ces problèmes, les tests ont été réalisés sur un système de fichiers créé sur une grappe en RAID0.
  • BLANKA : voulant au départ réaliser mes tests en RAID0, j’ai pu réaliser l’installation du système sous cette configuration sans problème, mais booter sur la grappe a été problématique. Il semble en effet que la configuration du boot sur une grappe doit être délivrée au serveur via BOOTP, ce qui est assez gênant pour un serveur censé être autonome. Les tests ont donc été réalisés sans utiliser le RAID.
  • DHALSIM : est un petit nouveau hors concours. Il s’agit d’un clone de Ryu exécuté dans une machine virtuelle sur mon PC desktop (Athlon X2 5200+ avec 2Go de RAM DDR2 et disques SATA-II). 1 seul processeur et 256 Mo de RAM sont alloués à la VM. Dhalsim participe aux tests uniquement afin d’avoir une vision plus large de ce que peuvent devenir les performances lors de l’utilisation d’une configuration plus récente, et donc plus musclée. Ses performances sont toutefois sous-évaluées car limitées par le cadre de la VM.

Tous les tests affichent un temps de traitement en secondes. Le meilleur résultat est donc le temps le plus faible.

Test 1 – Écriture d’un fichier de 1 Go sur le disque

Ce test fait uniquement intervenir principalement le disque dur, en écriture. La commande suivante a été utilisée :

time dd if=/dev/zero of=dummy.tmp count=2M

test1

Ici Ryu accuse le coup avec sa carte-mère limitant les taux de transferts en UDMA2. Zangief affiche des performances décevantes malgré une configuration en RAID0. Le plus rapide en SCSI sans RAID est Blanka, mais il est facilement distancé par Guile et Dhalsim sur des configurations respectivement UDMA5 et SATA-II.

Test 2 – Lecture d’un fichier de 1 Go à partir du disque

Comme le précédent, ce test met principalement en jeu le disque dur et son contrôleur, cette fois-ci en lecture. La commande suivante a été utilisée :

time cat dummy.tmp > /dev/null

test2

Zangief se démarque, en mal, par rapport au test précédent. Malgré des performances correctes de Blanka, celui-ci est battu par une solution IDE. Dhalsim est un peu à la traîne derrière Guile.

Test 3 – Génération d’un fichier random de 1 Go

Ce test met principalement en avant les capacités de calcul (donc en grande partie le processeur). La commande suivante a été utilisée :

time dd if=/dev/urandom of=random.tmp count=2M

test3

Le processeur de Dhalsim lui permet de tenir le haut de peloton. Guile fonctionne à une fréquence bien supérieure aux autres et remporte la seconde place. Les deux processeurs de Blanka ne semblent pas être de grande utilité pour ce test.

Test 4 – Compression d’un fichier de 1 Go

Tout comme pour le test précédent, c’est principalement le processeur qui sera sollicité ici. Le fichier en question est un fichier contenant des octets générés de manière aléatoire. Ce fichier est le même pour tous les tests. La commande suivante a été utilisée :

time bzip2 random.ryu

test4

Ici, les deux processeurs de Blanka semblent lui permettre de prendre le pas sur Guile, qui pour ce test semble donner des signes de faiblesse. Dhalsim affiche des résultats sans commune mesure et Ryu est comme d’habitude bon dernier.

Test 5 – Décompression du fichier obtenu en résultat du test précédant

Le processeur est beaucoup sollicité dans ce test, mais il n’est pas le seul. La commande suivante a été utilisée :

time bunzip2 random.ryu.bz2

test5

Le duel Blanka/Guile tourne cette fois-ci en faveur de ce dernier. Zangief est distancé mais il s’accroche. Ryu et Dhalsim affichent des résultats sans surprise.

Test 6 – Déplacement d’un fichier de 1 Go de partition à partition, sur le même disque

Le disque dur et son contrôleur seront pleinement sollicités ici, en lecture comme en écriture. Pour les systèmes non-SCSI, le processeur sera aussi de la partie. La commande suivante a été utilisée :

time mv random.ryu /tmp/

test6

Les trois configurations les plus puissantes sont ici au coude à coude. C’est cependant Guile qui remporte le duel. Zangief ne suit pas vraiment et confirme les soupçons évoqués sur ses performances avec un résultat bien en dessous de ce qu’il est possible d’espérer pour du RAID0. Ryu quant à lui montre clairement les limitations de l’UDMA2.

Test 7 – Scan par l’antivirus d’un fichier de 1 Go

Le scan a été effectué par Clamav. Ce test sollicite probablement la RAM de manière importante si l’on fait l’hypothèse que les définitions de virus y sont chargées avant le scan. La commande suivante a été utilisée :

cd /tmp ; time /usr/bin/clamscan -ri random.ryu

test7

Ryu étant borderline au niveau de son utilisation mémoire, a probablement été obligé de swapper, ce qui plombe inévitablement ses performances. Blanka est à la traîne et finit avant dernier. Curieusement, les temps de traitement sont inférieurs au temps de lecture d’un fichier de 1Go (cf Test 2), ce qui laisserait sous-entendre qui le fichier n’est pas balayé par l’antivirus dans son intégralité (voire quasiment pas).

Test 8 – Compilation du noyau linux-2.6.28.7

Le test ultime sollicitant à peu près toute l’architecture. La commande suivante a été utilisée :

cd /home/public/linux-2.6.28.7 ; time make bzImage modules

test8

Les deux processeurs de Blanka lui permettent de prendre plus de 10 minutes d’avance sur Zangief,  mais Guile met lui-même plus 9 minutes dans la vue de Blanka. Les deux extrêmes sont Dhalsim avec 10 minutes de traitement et Ryu avec 68 minutes.

Pour information, le tableau des résultats exacts

NomRYUGUILEZANGIEFBLANKADHALSIM
Photosa-thumb-1sa-thumb-2sa-thumb-3sa-thumb-4sa-thumb-5
Test 169.7530.4350.5139.8627.27
Test 253.0517.8742.2028.3620.93
Test 31612.61552.251233.18994.53233.94
Test 43207.971980.142250.421776.94620.07
Test 5977.69527.27713.40610.60245.47
Test 6216.6049.5788.6263.6861.89
Test 718.574.386.889.913.28
Test 84114.421602.402787.192150.66632.52

 Adieu Etch, bonjour Lenny

 4 mars 2009  Projet Serveur  Aucun commentaire
Powered by Debian

Powered by Debian

Une très brève pour signaler que le serveur a été totalement migré vers la version 5.0 « Lenny » de Debian, après une semaine entière dédiée aux tests sur virtual machine et aux installs d’updates pré-migration.

La migration a nécessité une mise à jour laborieuse du noyau, un long repaluchage des fichiers de configuration de nombreux services, et quelques mini-prises de tête pour cloisonner la migration par lots fonctionnels, principalement par excès de prudence.

Les performances de certains services s’en trouvent immédiatement boostées, et l’opération me permet de planifier l’ajout de nouvelles fonctionnalités dans les semaines qui viennent. Le serveur galère toujours un peu à afficher les pages WordPress (il y a du lourd derrière et mes I/O sont à la ramasse), mais si vous suivez correctements mes teasers vicieux, vous deviez soupçonner que la situation devrait s’améliorer dans quelques temps…