devoo - info pour les ours²

Un profiler est une application qui permet de monitorer (temps réel ou non) le fonctionnement d'un programme en details. On obtient par exemple un compte rendu sur les appels de fonctions, leur temps d'execution, le nombre d'instance de chaque type d'objet crée, la taille mémoire occupée.

Je voulais un profiler sur le programme de détection de véhicule, afin de voir si certaines parties étaient bloquantes. Le but de ce programme est d'obtenir une estimation des distances des véhicules rencontrés à l'instant x et à l'instant x + 3secondes et cela à partir d'une séquence vidéo de circulation filmé en condition réelle. Ce programme tourne quasiment en temps-réel sous windows sur les dell-670 en utilisant les 2 processeurs à 50%. Par contre sous linux, le programme est très ralenti (fonctionne à moins de 50 % du temps réel). Ne sachant pas comment monitorer chaque processeur independamment, je ne sais pas si la JVM sous linux arrive à répartir équitablement le travail. (@todo : trouver comment monitorer le bi-processeurs) Je voulais donc soir si une méthode particulière prenait un temps anormal. Cependant je n'ai pour l'instant pas détecter d'anomalies particulières. Je ne peux faire pour l'instant que des hypothèses :

• Il y a un problème d'I/O sous linux.
• Il y a un problème d'affichage sous linux.
• La JVM n'arrive pas à repartir le travail entre les deux processeurs.
• La fonction Java drawImage() est mal implémentée sous linux.
• Un autre problème est à l'origine du ralentissement.

J'ai continué à lire de la documentation sur la possible implémentation de threads "distribués". Pour assimiler les détails, il va falloir absolument que je me fasse un résumé sur :

• L'utilisation mémoire d'un processus (quel registre sont utilisé, etc ...)
• Evenements inhérents à la création de Threads.
• Utilisation mémoire d'un Threads et liste des dépendance coté utilisateur et kernel.

J'ai aussi relu avec attention la documentation sur la DJVM, qui pourrait finalement être une des possibilités à retenir. Le problème reste cependant présent pour les programmes en C.

Etant donné que les personnes les plus "aware" sont certainement celles qui produise le plus de résultat, j'ai envoyé un mail à Gian Paolo Ghilardi, l'auteur de "Consideration on openMosix". Il terminait son article en disant qu'il n'avait trouvé aucune solution pratique au problème de la migration des threads, mais qu'un jour ou l'autre Java et openMosix finirait par cohabiter. Je lui ait donc demandé si ce jour était arrivé. S'il ne réponds pas d'ici mercredi, j'enverrais un mail à Moshe Bar qui est à l'origine d'OpenMosix. Tant qu'à faire, autant prendre l'information à sa source.

Dure journée. J'ai les yeux complétement "Amsterdam-isé". J'ai pu tester en live ce que j'avais lu à savoir qu'OpenMosix ne migre pas les threads C (qu'ils aient été détachés ou non), que les green Threads sont mal gérés et que la seule possibilité se trouve vers des implémentations spéciales des threads (comme les Distributed Threads).

Demain, je vais essayer de moins lire de docs. Sinon, il y a des chances que je devienne fou et que je mange des Xéons :D

Au vu du nombre important de notions dont la maitrise risque d'être difficile, j'ai décidé de tenir à jour une sorte de mémo reprenant les principales informations.

Beowulf : premier système distribué réalisé (sur-couche de linux).

BTC (Bytecode-oriented Thread Context) : le BTC est composé de l'identificateur du thread et les informations sur la méthode (nom, signature, compeur de code et pile).

cluster : ensemble de machines éventuellement hétérogènes interconnectées à travers un réseau et permettant de répondre à un ou plusieurs besoins (puissance : HPC, qualité de service : HA, sauvegarde, traitement par lot...). L'augmentation de la ressource désirée n'est pas forcément linéaire au nombre de ressource disponible.

DHCP (@todo)

DJVM : Distributed JVM. JVM qui tourne sur plusieurs machines et permet de cacher la parrallélisation.

Distributed threads : Threads modifiés capables de fonctionner dans un mode distribué.

Ferme : voir cluster

Grappe : voir cluster

GridComputing : Surcouche d'OS (existe sous différentes plate-formes) permettant le clustering. Distribué par Sun.

HA : High Availability. Type de cluster permettant de garantir une grande qualité de service. Typiquement utilisé pour la gestion de services critiques et gourmand en ressources (Serveur web, ftp, mail).

HPC : High Performance Computing. Type de cluster permettant d'obtenir une puissance de calcul importante en répartissant les processus sur les différents noeuds du cluster.

HPJava : Librairies java basé sur MPICH permettant la parallélisation de partie de code, notamment grâce à des tableaux multidimension partageables.

JESSICA2 : JVM distribué autorisant la compilation à la volée.

JIT (Just In Time) : Compilation à la volée utilisée notamment pour pouvoir distribué les threads.

JNI : Java Native Interface. Couche permettant la communication et l'interaction entre Java et un autre langage implémentant JNI (C, C++).

JVM : Java Virtual Machine. Couche applicative spécifique à un environnement permettant d'exécuter du code java précompilé.

JVMDI : implementation Java de la librairie MPI.

MPI : Librairie de communication standart permettant l'échange de message en C entre différents programmes.

NFS (@todo)

NIS (@todo)

Node : machine faisant partie du cluster

Noyau : logiciel nécessaire au démarrage d'un système linux.

PVM : Librairie de communication permettant de répartir l'exécution de processus sur des machines hétérogènes.

OpenMosix : Surcouche (patch) du noyau. Implémentation "open-source" de Mosix.

Processus : Code indépendant pouvant donc être facilement migré.

PXE : Programme permettant de booter sur le réseau (@todo)

RMI (Remote Message Interface) : communication permetant la parralélisation de programme.

RPC (Remote Procedure Call) : Fonction qui permet à un serveur d'éxecuter une méthode chez un client.

RTC : (Raw Thread Context) : Espace virtuel alloué au thread + pile d'execution + registres privés

Rocks : OS dédié clustering. Utilise un Front-end spécifique.

SMP : @todo

SSI (Single System Image) : Se dit lorsqu'un front-end masque l'ensemble des machines pour ne se "montrer" que sous la forme d'une machine unique.

Supercalculateur : Cluster propriétaire composé de milliers d'éléments interconnectés selon une architecture spécifique.

TFTP : Trivial FTP. FTP ne gérant pas les utilisateurs. (connexion sans login/password)

Threads : Sorte de sous-programme dépendant du programme qui le lance. Utilise une partie des données dans le user-kernel et une autre dans le kernel-sytème. Il existe trois types de Threads en Java : les Threads gérés par la JVM, les Threads natif et les greens Threads.

Ma première journée s'est bien passée. J'ai retrouvé le labo tel qu'il était il y a deux ans.
Quelques changements au niveau des postes, des thésards qui sont devenus maitres de conf, des dea-iens qui sont devenus thésards.
Les pc composant le "futur" cluster sont sympatiques (cf photos) et puissants (Bi-Xéons 3ghz, 2 Giga de RAM) mais bruyants.

Après avoir lu mass doc, je me rends compte que je suis bien loin d'avoir assimilé toutes les notions "élémentaires" qui pourraient me permettre de valider certains points. Il va très certainement falloir aussi que je ramène un dico d'anglais au labo. Ou que d'un coup je devienne miraculeusement trilingue (ba tant qu'à faire autant que cela soit un vrai miracle).

De toute cette documentation avalée à la vitesse de lecture d'un tome de "Dune", quelques points devront faire l'objet d'une analyse demain :

Compilation noyau

• Choix de la distro (actuellement le labo utilise fedora core, je pensais utiliser debian, il suffira peut-être d'un noyau light avec quelques librairies suplémentaires)
• Quels seront justement les librairies à inclure si l'on installe un noyau minimal.
• Les pc sont de 2 types différents, fait-on un noyau spécifique ou un noyau global.

boot reseau

• Identifier carte reseau.
• Configurer et installer serveur de boot (pxe, dhcp, nfs)
• Installation en ram ou sur disque dur local

choix du système (openMosix)

• tester le système pour tenter d'estimer la charge que doit supporter le noeud "maitre) (ie : le premier noeud).
• vérifier/tester les limitations concernant la parrallélisation de programmes contenant des threads. (en C et en java)
• Trouver des infos sur RMI, sur les différences entres threads natifs/verts en java.

Ajout de job

• comment s'assurer que les jobs soient demandés par des personnes autorisées.
• lister possibilité : interface web, batch

A (re)lire

• utilisation de MPI, MPV

A tester

• utiliser un profiler java qui permet de montrer où se situent les points de charge du programme.

Quel est votre plus grande pathologie ?
L' hypotime. Un manque généralisé de temps

@toBeUpdated

openMosix :

• sf
• Faq
• howto

Beowulf

• Beowulf Web site
• installer cluster beowulf

Autre systeme

• cluster knoppix
• parrallel knoppix
• rocks
• gridcomputing

compilation noyau et openMosix

• compilation noyau debian
• compilation 2.4.4 gentoo

linux diskless

• ltsp
• diskless gentoo
• autocluster
• syslinux -pxe

articles sur les sytèmes distribués :

• jres
• ibm : clustering
• liste des choix

utilisation de cluster :

• utilisation de PBS

programmation

• PVM
• MPI

multithreader programmes java

• Jessica2
• ibm : supercomputer et java
• hpjava

Ressources et discussion autour des cluster, linux, noyau

• lcic
• hwfr : cluster
• yolinux
• forum gentoo

Evenements :

• cluster 2005

Et voila ! Avec les partiels s'acheve le premier semestre de master 1.
D'abord un petit bilan des exams (allez on prend les paris) :

• Anglais : 13/20
  
• Système : 12/20 (gros plantage sur une question a priori donnée)
  
• Réseau : 16/20
  
• Base de Données : 15/20
  
• Génie logiciel : 14/20
  

Concernant la formation, je ne sais pas trop quoi en penser.
On a vu des choses sympas, nouvelles mais rien de transcendant. Le deuxième semestre sera certainement plus ardu, au programme : IA, programmation logique, recherche opérationnelle, bref que du bonheur...si on aime les maths :D

Intitulé complet du sujet :

Configuration et installation d'un système d'exploitation HPC (High Parallel Computing) et parallélisation d'une plate-forme logicielle de simulation et d'optimisation des problèmes de routage de véhicules

Contexte :

Le domaine des transports constitue un secteur clef de l'économie. Du point de vue scientifique de nombreux problèmes afférents à ce domaine sont des problèmes de grande complexité dits "NP-difficiles". Les travaux menés au sein du Laboratoire de Génie Informatique et Automatique de l'Artois (LGI2A) concernent précisément la simulation et l'optimisation de problèmes d'optimisation combinatoire relatifs au domaine des transports connus sous le nom de VRP (Vehicle Routing Problem). Dans ce cadre, nous avons développé plusieurs plateformes de simulation et d'optimisation en Java et en C.

Une des perspectives prometteuses consiste à introduire des concepts de programmation parallèle et distribuée dans le but de traiter des problèmes plus complexes, par exemple en intégrant des paramètres plus réalistes (réseau routier réel, temps de parcours variable), en augmentant la taille des problèmes, ou en intégrant plusieurs objectifs (minimiser le nombre de véhicules, la distance totale parcourue). Pour atteindre ces objectifs nous avons acquis un réseau de 4 stations de travail biprocesseur (dell precision 650 muni de bipro Intel Xeon 3Ghz) reliées par un gigaswitch.

Participation de l'étudiant :

Le travail demandé fait suite à une étude préliminaire réalisée par un étudiant d'IUP en septembre 2004. Ce travail nous a permis d'avoir une étude détaillée (des avantages et inconvénients) des différents systèmes actuels capables de gérer un cluster de processeurs. Lors de cette période nous avons pu également installer et tester 2 systèmes linux (ROCK et Openmosix). Quelques programmes tests écrits en c ont été réalisés et le résultat est assez concluant.

Le travail demandé dans le cadre de ce stage TER consistera dans un premier temps à terminer l'étude, c'est à dire l'installation et la configuration d'un système d'exploitation distribué capable de gérer la répartition des processus de manière automatique et/ou manuelle, sachant que les processus peuvent être des processus unix ou des threads java. Parallèlement, une recherche des outils de développement, d'administration et de monitoring des processus devra être effectuée.

Une fois cet environnement de travail installé et configuré, l'étudiant devra s'intéresser à la parallélisation des applications développées au labo en java ou en c, effectuer des tests de la solution parallèle de manière à montrer sa faisabilité et compléter éventuellement les outils de monitoring par le développement des programmes utilitaires.

Mots clefs et liens :

• ROCKS, Openmosix, Clusterknoppix
• MPI (Message Passing Interface) : MPICH, LAM-MIP
• Java, Corba, Multithreading
• Algorithmes génétiques
• Routage de véhicules

Système d'exploitation :

• Linux

Remarques :

Le travail demandé touchera de nombreux domaines de l'informatique, tels que : l'administration d'un système unix, configuration d'un réseau, programmation parallèle en java ou en c, interopérabilité entre les applis java et c, optimisation de performances, ...etc.

Responsables :

Gilles Gonçalves : goncalves AT univ-artois.fr
Rémy dupas : dupas AT iut-gtr.univ-artois.fr
Tiente Hsu : hsu AT iut-lens.univ-artois.fr

Laboratoire d'accueil :

Laboratoire de Génie Informatique et Automatique de l'Artois (LGI2A)
Université d'Artois
Faculté des Sciences Appliquées
Techno Parc Futura
62400 Béthune
Groupe de travail ORE (Ordonnancement, Routage et Evolution)

J'ai fini ce soir (au lieu de réviser mon réseau...) la première version de ma classe benchoo qui permet d'afficher un reporting graphique sur des résultats de bench. Le projet permet actuellement de saisir manuellement les temps et le nom du bench et de créer une image au format PNG, reprenant :

• La moyenne du bench
• Le temps minimum et maximum
• L'histogramme des différents temps saisis

Je pense rajouter rapidement 2 autres fonctionnalités :

• Un format d'affichage (complet, minimal, normal) afin de pouvoir n'afficher que les informations pertinantes.
• Une personnalisation plus complete : saisie de l'échelle et précision des temps.

Si un hypothétique visiteur a une remarque à faire sur ce projet, il est le bienvenu.

Le mystère s'épaissit autour des chrétiens fanatiques !
Apparement leur dieu aurait besoin de la technologie microsoft pour s'imposer en utilisant frontpage comme l'instrument ultime de la propagande divine !
Heureusement, avec microsoft, nous autre les paiens, sommes sauvés des fous évangélisateurs.
En effet, même en étant un dieu, entre les reboots obligatoires, les patchs de sécurités à déployer, les failles de sécurité à monitorer et le renouvellement des licences, on risque pas de voir jésus lever le nez de son écran TFT 17 pouces.

Lorsque l'on voit que les fanatiques chrétiens demande à leurs fanatiques fidèles de faire des liens en dur pour briguer les premières places de google sur les requêtes-clées de leur(s) bêtise(s) religion(s), je finis par me demander à quel saint du référencement me vouer.
Heureusement, en plus de mal spammer actulab, on voit que les bergers ont visiblement du mal avec leur référencement tant celui-ci fait pitié à voir.
Peut-être que bientôt l'obôle des églises servira à acheter des adwords !
Finalement si même quelques dieux supplient google, notre vrai dieu à tous n'est-il pas celui-ci ?

Je suis en train de préparer différentes petites choses :

• La fin de "l'article" sur le stockage/transformation d'adresse ip, cette fois du côté de la base de données.
• Une classe de benchmark simple (comme la classe benchmark de pear) produisant un report sous forme d'image (histogrammes des differentes mesures + moyenne).
• Je finis mon adaptation de geshi (un analyseur syntaxique multi-langage). Le seul problème restant est que le parsing de geshi ne permet pas de repasser plusieurs fois pour trouver plusieurs fois la même fonction. Donc certains appels de fonction ne sont pas liés à la page de documentation sur php.net.
• J'ai encore une vieille fonction de simulation de requete 'post' à finir. (Le but ultime étant de récupérer les références d'un bouquin sur amazon à partir de son titre :d).

Bref je suis pas couché. Je crois que le voyage à Amsterdam risque d'être reporté..

Et ben voilà. Je m'absente quelques jours. Ma soeur va sur le pc. Utilise Internet Explorer (dommage il restait une icone que j'avais oublié). Et là c'est le drame.
Je rentre et j'ai un chien qui apparait et me demande si je veux m'inscrire à la banque parce qu'il a de super contrats à me proposer...
Un coup d'antispyware (Ad-aware) et hop 782 "incidents" sont detectés. Vive ie. Je me demande quand même pourquoi microsoft avec le nombre de développeurs et un budget aussi conséquent n'arrive pas à faire de ie un navigateur sympa.
M'enfin de toute façon il est trop tard, j'ai éradiqué toutes les icones de ie et de toute façon mon fixe va pas tarder à migrer sous un OS dont l'aquisition de la licence ne devrait pas me couter trop cher :)

Bon ca y est. Je l'ai. Mon Stage. Mon mien quoi. Il n'a pas été volé par un inconscient dont j'aurais été forcé de fouetter le corps avec des orthies génétiquement modifiés (ba oui les ogm quoi...). Preuve également que tout espoir dans l'humanité n'est pas perdu et qu'il existe des gens capable de respecter autrui.

Revenons en détails sur les différentes étapes de ces derniers mois :

Présentation du module "stage"

"Bon ben en gros c'est sur quatre mois pendant le deuxième semestre. Lundi et mardi vous êtes à la Fac et le reste de la semaine vous êtes en entreprise.". Stupeur et tremblement. Non seulement, on est pas dans une coin hyper informatisé (à par les distributeurs de billet du stade bollaert), non seulement ça fait ringard, limite pouilleux d'alterner les jours de fac et d'entreprise (on arrive en milieu de semaine genre en vacance), non seulement on ne pourra pas bosser sur le programme de fin de master1 mais, en plus, cela restreint le rayon possible de recherche notamment pour ceux qui ont une piole sur lens.

Le choix du sujet à demander.

J'ai hésité un certain temps à partir vers du réseau. Finalement, je privilégie un mélange des genres. Cette année cela sera administration linux, programmation système et réseau. Je nage sous linux. Depuis que je suis en only Ubuntu sur mon portable, je n'ai pas l'impression d'avoir vraiment progressé. Je survole quelques fonctionnalités mais finalement je reste plus GUI's user que geek's powered. Un pti stage sous nunux, me fera le plus grand bien. Quand à la prog système, c'est son côté psykopate qui me laisse rêveur.

Choix du stage.

Je contacte tout d'abord aquastar, une boite sympa ou travaille un baua. Quelques mails sympa, des sujets qui évoluent vers ce que je souhaite sans qu'aucun d'eux ne me fasse sauter de frénésie et ne me donne envie de coder 72 heures non-stop. Je commence alors à me dire que ce que je cherche à réaliser risque d'être difficilement faisable dans une boite privée. Je fais alors le tour des offres de stages de differents laboratoires de recherche et je recommence à espèrer. Je trouve notamment des projets bien goutus, qui sont malheureusement trop loin pour je puisse y prétendre. J'envoie également une liste de sujets possibles et de domaines dans lesquels j'aimerais bien bosser à M.Hsu du LGI2A. Et paf, miracle ils viennent de faire l'aquisition de plusieurs machines biprocesseurs et veulent clusteriser tout ça afin d'optimiser les temps de traitement. Il s'en sort un sujet qui me convient parfaitement, alliant réseau, prog système et administration linux.

Demande de validation du stage.

L'étape à priori la plus facile, rapide et triviale. Sauf que m'explique-t-on, les modalités de l'attribution des stages en laboratoire est differente de celle des stages en entreprise. Les étudiants qui trouvent un stage en labo (interne à l'université d'artois) voient leur stage ajouté à la liste proposée par les profs et donc disponible pour tous les étudiants. Les stages étant ensuite attribués aux étudiant selon leurs choix et leur moyenne de licence. Mon stage est donc nationnalisé et peut être potentiellement pris par un étudiant ayant eut une meilleure moyenne que moi l'an passé (oui cela existe :p). Je prépare alors ma batte en alu 18 mm tout en demandant à mes camarades prolétaires de considérer ce stage en jachère.

Attribution du stage.

Je rentre chez moi, relève mes mails et hop la bonne nouvelle du week-end, j'obtient finalement le stage que j'avais proposé.

Merci à tous les étudiants qui ont joué le jeu et n'ont pas fait les traitres pour mon sujet ni pour celui du taulier :). Merci au prof qui m'a soutenu. Voila je peux me mettre à lire de la documentation. J'ai 2 gigas de pdf qui m'attend, je vais avoir du mal à tout lire tout en révisant mes partiels.

N'empèche je trouve cette méthode incorrecte et inadaptée. Que les labos n'aient pas vocation à faire du recrutement soit. De là, à court-circuiter les contacts établis par les stagiaires et leurs tuteurs...

Transformation PHP

Un problème qui se pose souvent lors de la création de module permettant le suivi et l'analyse des visites est le stockage des adresses ip. En effet, différentes solutions sont envisageables. Faisons rapidement le tour de celles-ci :

Solution 1 : vérification simple

stockage direct de l'adresse ip.

Avantage : aucun coût de transformation et une grande visibilité.
Inconvénient : Stockage dans la base en varchar (la taille pouvant varier de 7 à 15 caractères). Coût de comparaison important.
Requis : explode : PHP >= 3

Solution 2 : codage hexadecimal

stockage de l'adresse en hexadecimal (base 16). Etant donné la spécificité de la plage d'adressage (de 0 à 255), on peut donc stocker l'adresse sur 8 caractères (exemple : 192.168.0.1 devient c0a801).

Avantage : stockage sur 8 caractères (fixe et reduit). Facile a convertir.
Inconvénient : Temps de comparaison encore long, temps de transformation long.
Requis : ctype_digit : PHP >= 4.0.4

Solution 3 : codage par décalage

stockage de l'adresse par décalage. On ajoute au fur et à mesure les quatres parties de l'adresse en opérant un décalage de 256 (é puissance 8) à chaque tour et en ajoutant la sous-partie suivante. (exemple : 192.168.0.1 devient 3198681089). Utilisation et uniformisation de la fonction ip2long en renvoyant false en cas de problème sur l'ip (et pas -1 en php 4 et false en php5).

avantage : facilite de comparaison, temps de conversion très rapide (trois fois plus rapide que ipv4_to_hex).
inconvenient : stockage de type long
Requis : ctype_digit : PHP >= 4.0.4

temps pour générer 25146 adresses (moyenne sur 5 essais)

Solution 1 : 0,446603489 sec
Solution 2 : 1.52481599808 sec
Solution 3 : 0,410049963 sec

Dès lors on peut envisager plusieurs hypothèses selon le type de traitement que l'on veut réaliser. Pour une consultation rapide des adresses, le stockage direct des ip peut être envisagé. Pour une taille de stockage minimale on peut passer par une compression de l'adresse en hexadécimal. Enfin pour une comparaison d'adresse : logs, surveillances, la transformation par décalage semble idéale.

à suivre comparatif recherche/stockage des adresses ip dans MySQL

Très bon film koréen pour passer une soirée romantique avec votre dulciné(e). Pas de chance moi je l'ai vu à l'hopital alors que ma chère et tendre venait de se faire enlever les quatres dents de sagesse. Pour le romantisme, on repassera. Il n'empeche que ce film, sans artifices tape-à-l'oeil, sans histoire extraordinaire est tout simplement beau et les comédiens sont superbes.

Pour résumer, un étudiant koréen qui a fait une partie de ses études (sa vie ?) aux états-unis revient au pays et tombe amoureux d'une jeune femme un peu plus vieux que lui. Celle-ci le rejette et quelques années plus tard épouse un ami commun. Qui est tué ainsi que les parents de la fille dans un accident de voiture. Il tente alors de la reconquérir mais ce qu'il obtiendra finira de toute façon par le rendre triste.

Ce film montre également le poids des traditions en korée. La fille se refuse parce qu'elle est plus vieille de quelques années. La demande en mariage est examinée par les parents de façon réfléchie mais également de façon à toujours respecter cette tradition. Enfin cette politesse "excessive", que l'on pourrait ici appeler servilisme, semble tellement normale là-bas qu'on fini par se demander si ce n'est pas nous qui sommes finalement méprisant.

A voir :
rien pour l'instant

Relatif :
acheter bande originale scent of love
acheter affiche - poster scent of love
acheter DVD scent of love
acheter VHS scent of love