Poursuite des exp´erimentations

On peut remarquer que les d´ebits obtenus sont de l’ordre de 4 ou 5 Mo/s. Ce d´ebit peut paraˆıtre faible en regard de la capacit´e du r´eseau d’interconnexion de Grid5000, mais c’est en moyenne l’ordre de grandeur du d´ebit obtenu pour un transfert utilisant une seule connexion TCP entre deux sites distants. Cette limitation est principalement due `a la taille de la fenˆetre de congestion de TCP, c’est-`a-dire la fenˆetre contenant des messages qui ont ´et´e envoy´es mais dont l’acquittement n’est pas encore parvenu ; le d´ebit obtenu correspond `a la limitation W_max/RT T bien connue de TCP [82], avec une taille de fenˆetre de congestion W_max de l’ordre de 20Ko, et un temps d’aller-retour (round trip time, RTT) de quelques millisecondes, ce que l’on observe entre deux sites.

Comme nous utilisons une connexion TCP pour une communication entre deux agents, nous ne pouvons esp´erer d´epasser cet ordre de grandeur. Nous sommes actuellement en train

de modifier notre implantation pour pouvoir d´epasser cette limitation. Deux solutions sont envisageables :

– D’un point de vue syst`eme, on envisage de reconfigurer la taille de la fenˆetre de congestion de TCP pour l’adapter `a la capacit´e des liens de communication ; ceci n´ecessite de disposer de droits particuliers sur les machines utilis´ees, afin de pouvoir ajuster des param`etres que seul l’administrateur des machines peut habituellement modifier. Bien que cela soit possible sur Grid5000, en d´eployant une image syst`eme particuli`ere, peu de plates-formes offrent autant de libert´e. Enfin, la configuration de TCP est tr`es d´ependante du syst`eme utilis´e.

– Plutˆot que modifier la configuration TCP, nous pouvons utiliser plusieurs connexions simultan´ees pour atteindre la capacit´e r´eellement disponible sur un lien de communication. En effet, plusieurs connexions peuvent coexister sur un mˆeme lien de communication sans entraˆıner de congestion, tant que leur d´ebit total ne d´epasse pas le d´ebit offert par le r´eseau ; nous d´evelopperons un tel mod`ele dans le chapitre 7, pour l’ex´ecution de tˆaches divisibles sur une grille de calcul. On peut donc utiliser plusieurs connexions concurrentes pour un mˆeme transfert. Nous sommes donc en train d’adapter notre implantation pour nous rapprocher du mod`ele d´ecrit dans la section 7.2.

On peut souhaiter qu’`a terme, la configuration de TCP sur les plates-formes distribu´ees sera effectu´ee par les administrateurs de la plate-forme, ou bien que d’autres protocoles que TCP plus adapt´es `a ces r´eseaux seront utilis´es, afin qu’il soit possible d’obtenir un d´ebit proche du d´ebit physique annonc´e sans recourir `a de telles strat´egies.

Conclusion

Dans cette partie, nous avons pr´esent´e les exp´erimentations que nous avons men´ees pour ´eva-luer l’int´erˆet de nos strat´egies de diffusion pipelin´ee. Nous avons introduit un nouveau mod`ele de communication, le mod`ele multi-port born´e et montr´e qu’il pouvait ˆetre utilis´e dans notre ´etude des communications collectives. Les r´esultats des exp´erimentations pr´esent´ees ici montrent que malgr´e tout, le mod`ele un-port bidirectionnel convient mieux `a l’´elaboration de strat´egies de communications collectives, et parmi les strat´egies fond´ees sur ce mod`ele, la strat´egie d´ecompo-sant la solution du programme lin´eaire donne de meilleurs r´esultats, comme attendu.

Ces r´esultats pourrait ˆetre compl´et´es par de nombreuses autres exp´erimentations, et il serait sans doute int´eressant d’int´egrer quelques unes de ces strat´egies `a une biblioth`eque de commu-nication pour la grille, afin de comparer ces heuristiques `a des biblioth`eques existantes comme MagPIe [69] ou ECO [78].

Seconde partie

Ordonnancement d’applications

multiples

Chapitre 6

Collections de tˆaches ind´ependantes en

maˆıtre-esclaves

6.1 Introduction

Dans ce chapitre, nous nous int´eressons `a l’ex´ecution concurrente de plusieurs applications sur une plate-forme de calcul distribu´ee. Ces applications se partagent les ressources de calcul et de communication disponibles, et nous voulons assurer une ex´ecution efficace et ´equitable. Nous visons des plates-formes de type maˆıtre-esclaves : un processeur ✓maˆıtre✔ distribue des tˆaches `

a diff´erents processeurs✓esclaves✔ travaillant pour lui. Une plate-forme de ce type est souvent mod´elis´ee par un graphe en ´etoile : le maˆıtre, au centre, est reli´e `a tous les autres processeurs. Nous utilisons un mod`ele un peu plus g´en´eral, qui convient mieux aux plates-formes `a grande ´echelle : les esclaves avec qui le maˆıtre communique peuvent eux-mˆemes d´el´eguer du travail `a d’autres esclaves. Le graphe de la plate-forme est donc un arbre.

Nous consid´erons que chaque application est constitu´ee d’un grand nombre de tˆaches de mˆeme taille et tous les fichiers de donn´ees associ´ees `a ces tˆaches sont initialement pr´esents `a la racine de l’arbre. Ceci correspond `a un ordonnanceur centralis´e qui distribue des tˆaches, comme le fait BOINC [103], qui distribue des tˆaches pour diff´erentes applications telles que SETI@home, ClimatePrediction.NET et Einstein@Home. Ces applications peuvent ˆetre de nature diff´erente, comme du traitement de fichiers, de l’analyse d’image, ou des op´erations sur des matrices. Chaque application a donc deux param`etres caract´eristiques, une taille de fichier d’entr´ee et une quantit´e de calcul par fichier. `A chaque application est ainsi associ´e un rapport coˆut de communication sur coˆut de calcul, identique pour toutes les tˆaches d’une mˆeme application, mais variable d’une application `a l’autre. Ce rapport se r´ev`elera un param`etre important pour l’ordonnancement.

L’ordonnancement de tˆaches ind´ependantes a d´ej`a ´et´e ´etudi´e, en particulier pour une seule application, sur des plate-forme maˆıtre-esclaves : voir par exemple [92, 91] pour une approche fond´ee sur l’´etude d’un flot dans le r´eseau (utilisant un mod`ele multiple-port non born´e), ou [60] pour une strat´egie adaptative. D’autres travaux [56,98] pr´esentent des m´ethodes pour faciliter l’implantation d’ordonnanceurs maˆıtre-esclaves pour les tˆaches ind´ependantes. Enfin, pour le mˆeme mod`ele de plate-forme que nous utilisons, une strat´egie optimale simple a ´et´e d´ecrite dans [17, 10] pour l’ordonnancement d’un seul type de tˆaches ind´ependantes ; il a ´egalement ´et´e montr´e [70] qu’une implantation dynamique de cette strat´egie donnait un d´ebit proche de

l’optimal, en utilisant une m´emoire de taille limit´ee. Nous la d´ecrirons plus loin lorsque nous l’utiliserons pour construire des heuristiques d´ecentralis´ees.

Nous ´etudions ce probl`eme dans la perspective du r´egime permanent et nous int´eressons donc `a maximiser le d´ebit de chaque application (le nombre de tˆaches effectu´ees par unit´e de temps), plutˆot que de consid´erer le temps total d’ex´ecution de toutes les tˆaches. D’autre part, nous consid´erons le cas g´en´eral o`u les applications sont munies de priorit´es w<sup>(k)</sup>, qui quantifient leur importance relative : si une application A<sup>(1)</sup> a une priorit´e w<sup>(1)</sup>= 3 et une application A<sup>(2)</sup> a une priorit´e w(2)= 1, on cherchera `a traiter trois fois plus de tˆaches de A(1) que de A(2).

Pour chaque application A^(k), on appelle ν^(k)(t) le nombre de tˆaches de cette applica-tion effectu´ees en temps t. `A tout instant t, on peut d´efinir le d´ebit de l’application A(k) : α<sup>(k)</sup>(t) = ν<sup>(k)</sup>(t)/t. En r´egime permanent, nous consid´ererons que α<sup>(k)</sup> est le nombre moyen de tˆaches effectu´ees par unit´e de temps. Afin de garantir une ex´ecution ´equitable, nous cher-chons `a maximiser le minimum des d´ebits pond´er´es : min_kα(k)(t)/w(k). Cette fonction objective correspond `a l’´equit´e max-min [25, 79] entre les diff´erentes applications, munies de coefficients 1/w^(k).

Nous allons nous int´eresser `a l’´elaboration d’ordonnanceurs centralis´es et distribu´es. Nous verrons que dans le cas centralis´e, lorsque nous pouvons rassembler une information compl`ete et fiable sur la plate-forme sur le maˆıtre, nous pouvons calculer le d´ebit optimal. Cependant, sur des plates-formes `a grande ´echelle, en particulier lorsque les ressources disponibles ´evoluent, un ordonnancement centralis´e n’est pas souhaitable. Nous ´etudions donc des ordonnanceurs locaux, s’appuyant uniquement sur des informations locales (vitesse des processeurs et capacit´es des liens). Nous cherchons `a savoir si de tels ordonnanceurs d´ecentralis´es peuvent atteindre le d´ebit optimal. Nous proposons plusieurs heuristiques d´ecentralis´ees, et nous les comparons par simulation `a un ordonnanceur centralis´e.