M´ ethodologie

Pour tester ces diff´erentes strat´egies pour la diffusion pipelin´ee de messages, nous avons d´ e-velopp´e une implantation distribu´ee g´en´erique, qui permet d’effectuer une diffusion de messages selon un ou plusieurs arbres pond´er´es. Le contrˆole de cette application distribu´ee s’apparente `a une application maˆıtre-esclaves : un processus maˆıtre contrˆole l’ex´ecution de plusieurs esclaves, ou agents. Chaque agent poss`ede donc un processus l´eger (outhread) qui dialogue avec le maˆıtre, pour recevoir les consignes d’ex´ecutions et renvoyer les r´esultats obtenus (le d´ebit de r´eception qu’il a observ´e).

En fonction des consignes re¸cues du maˆıtre, un agent cr´ee pour chaque arbre de diffusion, les processus l´eger suivants :

– si l’agent n’est pas la source de la diffusion, un processus de r´eception est cr´e´e, qui stocke les messages re¸cus pour cet arbre dans une m´emoire tampon,

– si l’agent n’est pas une feuille de l’arbre, un processus l´eger d’´emission est cr´e´e pour chaque fils du nœud dans l’arbre : c’est lui qui se charge de transmettre les messages stock´es dans la m´emoire tampon `a ce fils.

processus maˆıtre

E

E R

R

E

C M

M

Fig. 5.1 – Structure d’un agent communiquant, pour deux arbres de diffusions. Les processus l´egers E,R et C sont respectivement les ´emetteurs, r´ecepteurs et le coordinateur qui re¸coit les consignes du maˆıtre et lui renvoie le d´ebit de r´eception. M d´esigne la m´emoire tampon pour chaque arbre de diffusion.

La figure5.1 repr´esente l’architecture du programme obtenu.

Une m´emoire tampon est donc cr´e´ee pour stocker les messages re¸cus qui doivent ˆetre retrans-mis. Cette m´emoire est de taille fixe (capable de contenir 20 messages dans nos exp´eriences) et elle est utilis´ee de fa¸con circulaire (du typeround-robin). Avant de r´eutiliser une case de cette m´emoire pour stocker un nouveau message arriv´e, il faut s’assurer que tous les agents ´emetteurs ont bien r´e´emis le message qui s’y trouvait. Ceci est fait `a l’aide de s´emaphores, en utilisant un m´ecanisme classique de producteurs/consommateurs.

Plusieurs arbres peuvent ˆetre utilis´es simultan´ement. Pour ´eviter que les messages de diff´ e-rents arbres ne s’interchangent, chaque arbre utilise un port de communication TCP diff´erent : lors de l’´etablissement des connexions, un processus r´ecepteur qui vient d’ˆetre cr´e´e signifie au maˆıtre son adresse IP et le port sur lequel il ´ecoute. Ces informations sont ensuite transmises au processus ´emetteur qui doit lui envoyer les messages de cet arbre, qui peut alors initialiser la connexion. De plus, les messages sont ´etiquet´es avec leur num´ero dans la s´erie et l’arbre sur lequel ils sont diffus´es, ce qui permet de v´erifier la coh´erence de ces informations `a chaque r´eception d’un nouveau message. Lorsque plusieurs arbres sont cr´e´es, le nombre de messages `a diffuser sur chaque arbre est calcul´e pour ˆetre proportionnel au d´ebit qu’on d´esire lui affecter.

On fournit au processus maˆıtre un fichier de description de la plate-forme `a utiliser, qui lui permet de contacter chaque agent, et un fichier d´etaillant les tests `a effectuer. C’est lui qui ex´ecute les algorithmes des diff´erentes heuristiques pr´esent´ees ci-dessus, qui d´etermine et distri-bue aux agents les consignes permettant d’effectuer la strat´egie voulue. Pour chaque diffusion,

nous utilisons une s´erie de 10 000 messages de taille 20 000 octets, ce qui conduit `a des tests de quelques minutes. Ces messages sont g´en´er´es de fa¸con al´eatoire par le nœud qui se trouve `a la source de la diffusion. `A la fin d’une op´eration de diffusion, le maˆıtre re¸coit le d´ebit de r´eception de chaque nœud et calcule le minimum de ces d´ebits, qui est consid´er´e comme le d´ebit de la diffusion. Il est ensuite possible de red´emarrer une autre op´eration de diffusion, avec d’autres param`etres, sans d´eployer `a nouveau toute l’application.

Topologie de tests

Le projet Grid5000 vise `a construire une grille de calcul fran¸caise pour la recherche, en rassemblant des machines localis´ees dans neuf sites en France. Le nombre de processeurs, qui doit atteindre 5000 `a terme, est `a l’heure actuel de pr`es de 2500. Les sites et leur r´eseau d’in-terconnexion par Renater 4 sont repr´esent´ees sur la figure 5.2(a). Dans la p´eriode o`u nous avons conduit nos simulations, nous avons pu avoir acc`es `a 75 machines, r´eparties sur huit sites (Rennes, Nancy, Orsay, Lyon, Grenoble, Lille, Sophia-Antipolis et Bordeaux). Ces machines sont r´eparties comme illustr´e sur la figure 5.2(b). Chaque ensemble de machines dans un mˆeme site est mod´elis´e comme un graphe compl`etement connect´e, et nous ajoutons des liens distants en nous inspirant de la topologie r´eseau de Grid5000. Le choix de ces liens longue distance est un peu arbitraire, car rien ne nous empˆecherait d’ouvrir une connexion entre par exemple Rennes et Sophia-Antipolis, mais nous tentons de prendre en compte les informations sur la topologie du r´eseau de la figure 5.2(a). Le graphe d’interconnexion de ces sites utilis´e par la suite est d´ecrit `a la figure 5.2(b).

(a) Le r´eseau Renater 4 reliant les sites de Grid5000.

9 10

10 10

5

9

7 5

10

(b) Topologie utilis´ee pour les tests

Fig. 5.2 – Plate-forme de test, avec le nombre de machines utilis´ees sur chaque site. Les deux cercles pour Rennes repr´esentent deux grappes de calcul situ´ees sur un mˆeme site g´eographique, mais consid´er´ees comme deux sites distincts.

Pour pouvoir utiliser les diff´erentes strat´egies de diffusion, nous devons instancier les para-m`etres de la plate-forme. Pour le mod`ele de communication un-port, nous devons par exemple connaˆıtre le coˆut d’envoi d’un message de taille unit´e sur chaque arˆete, c’est-`a-dire mesurer ces

valeurs sur la plate-forme. Ces mesures sont effectu´ees par l’application elle-mˆeme, en utilisant un petit arbre de diffusion : pour tester la capacit´e de l’arˆete (i, j), nous cr´eons un arbre avec P_source=P_iet comportant une seule arˆete (i, j). Une fois le d´ebit de r´eception mesur´e et renvoy´e au maˆıtre par Pj, le maˆıtre connaˆıt la bande-passante de l’arˆete (i, j). Ainsi que nous l’avons

´

enonc´e dans la pr´esentation du mod`ele multi-port (partie 5.1), nous supposons que le coˆut de transmission d’un message de taille unit´e est l’inverse de la bande-passante.

Pour le mod`ele multi-port born´e, le maˆıtre doit connaˆıtre la bande-passante de chaque lien, d´ej`a mesur´ee, et la bande-passante total en sortie et en entr´ee de chaque processeur. Pour calculer la bande-passante en sortie d’un processeurPi, nous cr´eons ´egalement des petits arbres de diffusion, enracin´es en Pi. Un arbre est cr´e´e pour chaque arˆete sortante (i, j) de Pi, qui ne comporte que cette arˆete. Nous mesurons le d´ebit total en sortie deP_i et consid´erons qu’il s’agit de la bande-passante Bout(Pi). Remarquons qu’il aurait ´et´e tentant d’utiliser un seul arbre de diffusion, dont la source serait Pi et qui aurait comme arˆetes toutes les arˆetes sortantes de Pi

dans G. Cependant, `a cause de la taille limit´ee de la m´emoire tampon contenant les messages

`

a envoyer, toutes les connexions sortantes verraient rapidement leur d´ebit align´e sur le d´ebit minimal d’une connexion. Nous pr´ef´erons donc cr´eer des arbres diff´erents pour chaque arˆete, qui ont chacun leur propre m´emoire tampon, et ne sont donc pas limit´es par les autres arˆetes.

Nous proc´edons de mˆeme pour la bande-passanteB_in(P_i) en entr´ee d’un processeur P_i.

Toutes ces mesures pr´eliminaires de bande-passante sont effectu´ees en diffusant 1000 mes-sages de tailles 20 000 octets, ce qui prend quelques secondes pour chaque test. On peut se permettre d’utiliser un nombre de messages plus petit que pour mesurer le d´ebit d’une diffu-sion, car l’obtention du r´egime permanent est beaucoup plus rapide sur une seule arˆete, ou un petit nombre d’arˆetes entrant ou sortant d’un nœud, que sur un ou plusieurs arbres de diffusion couvrant tous les nœuds.