Site ELEC344/ELEC381

Partie interactive du site pédagogique ELEC344/ELEC381 de Télécom ParisTech (occurrence 2010).

Catégories

Etude de cas : processus de décision répartis

Aujourd’hui, j’ai effectué quelques recherches sur internet pour mon exposé. J’ai essentiellement ciblé les algorithmes d’élection de leader (en attendant d’autres directions…). Les algorithmes les plus souvent présentés étaient l’élection sur un anneau unidirectionnel, bidirectionnel. Mais il en existe aussi pour les réseaux en forme d’arbre (plus complexe) !

Concernant GLiP, nous avons réfléchi au format de stockage des animations dans les modules et commencé quelques calculs de dimensionnement. Il en sort (cf wiki) qu’une animation de 20 images tiendrait sur 60kB, ce qui soulève certaines questions concernant la capacité de stockage des modules puisque le micro-contrôleur proposé n’embarque que 64kB de RAM au plus.

Nous avons aussi établit une liste de tâches que nous pouvons commencer dès maintenant (voire même un peu plus tôt !…), sans dépendre de la réalisation de la carte : format des images, dimensionnement (prioritaire !), logiciel de conversion vers ce format depuis les formats usuels.

4 comments to Etude de cas : processus de décision répartis

  • Samuel Tardieu

    Il en sort (cf wiki) qu’une animation de 20 images tiendrait sur 60kB, ce qui soulève certaines questions concernant la capacité de stockage des modules puisque le micro-contrôleur proposé n’embarque que 64kB de RAM au plus.

    Mais pourquoi voudrais-tu stocker toutes les images en entier dans toutes les cartes ?

    Et quel est l’intérêt de stocker dans les cartes les images au format GIF (ou PNG ou whatever) alors que ce sont des formats de *fichiers* ?

  • Florent

    Si on veut que l’animation se rétablisse lorsqu’on inverse deux blocs, on avait pensé que ça serait plus simple que l’intégralité de l’animation soit stockée dans tous les blocs. Comme ça, lors d’un déplacement il faut juste détecter sa position et afficher la bonne portion.

    Pour le format d’images, je pense que je me suis mal exprimé. Pour le moment, nous pensons stocker une image en donnant la quantité R,V,B pour chaque LED, ce qui mène au calcul du wiki. Il y a mieux ?

  • Samuel Tardieu

    C’est là que les algorithmes de synchronisation et d’échange de données vont devenir utiles : ils permettent de répartir la connaissance tout en offrant la possibilité de faire migrer les données lorsque c’est nécessaire. Tu peux imaginer que chaque bloc veut connaitre au moins ce qu’il doit afficher, mais qu’il garde également les informations d’un certain nombre d’autres blocs, et qu’une procédure de localisation automatique et répartie permet de récupérer les données qui concerne un bloc particulier s’il n’en dispose pas encore.

    Par exemple, cela permet au bloc « maître » qui veut charger de nouvelles images de déclarer lorsqu’il voit une recherche qu’il connait tous les blocs (ce bloc maître étant relié à un PC et disposant donc de plus de stockage potentiel) : du coup, chaque bloc qui cherchera à localiser les données qui le concernent feront une demande répartie, et le maître répondra positivement, causant ainsi une copie des données vers le bloc concerné. Une fois que tous les blocs ont leurs données, le maître peut disparaître sans provoquer de perte d’informations.

    Ce mécanisme est similaire à BitTorrent, où au départ seul un « seeder » dispose du fichier, mais où la connaissance est ensuite répartie entre les différents « peers » qui, à eux tous, disposent de l’ensemble du fichier partagé, même si personne ne l’a en entier.

  • Sinon, il y a http://bit.ly/cJlakX ou http://bit.ly/bxWrey
    Au fait, a-t-on réellement besoin de 8 bits par composante ? Est-ce que 4 bits ne suffiraient pas ? Qu’en disent les gens qui ont essayé ? Et quid des palettes ?