Réseau longue distance et application distribuée dans les grilles de calcul

Application MPI sans contrôle de congestion

Le contrôle de congestion permet d’émettre un flux à un débit au plus proche de la bande passante disponible sur le lien. Comme le trafic des applications MPI étudiées n’est pas suffisant pour congestionner le lien longue distance, il est envisageable de supprimer le contrôle de congestion en l’absence de goulot d’étranglement sur le WAN, il devrait y avoir peu de pertes. Nous espérons ainsi émettre plus rapidement en n’étant pas limité par la fenêtre de congestion. Nous avons donc étudié si le contrôle de congestion était nécessaire pour l’exécution d’applications MPI dans une grille. Nos expériences ont porté sur l’exécution des NPB sur des noeuds sur lesquels le contrôle de congestion a été désactivé. Ceci est réalisé en utilisant un module de TCP modifié [SG09] qui force la fenêtre de congestion à une taille qui ne limite pas les émissions sur des liens 1 Gbit/s. Nous utilisons 8 noeuds sur chaque site, reliés par un WAN à 10 Gbit/s et avec 11.6ms de latence. La figure 4.3 présente le temps d’exécution sans contrôle de congestion normalisé par rapport au temps où il est activé. Toutes les applications sont impactées par l’absence de contrôle de congestion exceptés MG et CG. Les performances de IS sont catastrophiques car tous les processus communiquent de manière synchrone et dans un temps très limité. Cette chute de performance est due à l’augmentation des pertes et des retransmissions lorsque l’on supprime le contrôle de congestion. En effet, si plusieurs noeuds communiquent vers le même noeud distant, l’interface ne pourra pas traiter tous les paquets reçus. Le contrôle de congestion est donc nécessaire pour réguler les congestion locales même si le WAN ne constitue pas un goulot d’étranglement puisqu’il offre une bande passante supérieure au débit des noeuds qui communiquent dessus. Nous allons donc évaluer en détail l’influence de chacune des phases du contrôle de congestion de TCP sur les communications MPI. 72 0 1 2 3 4 5 6 bt cg ft is lu mg sp Temps d’execution relatif Avec controle de congestion Controle de congestion desactive Fig. 4.3 – Temps d’exécution des NPB sans contrôle de congestion relatif au cas avec contrôle de congestion. 

Impact du démarrage lent

Dans cette section, nous analysons l’impact du démarrage lent (slowstart) qui permet de déterminer la bande passante disponible sur un lien au début d’une communication. Ce mécanisme, décrit en annexe 4.2.1, positionne la fenêtre de congestion à 2 paquets puis la fait croître de manière exponentielle à chaque réception d’un ACK. On quitte cette phase dès qu’une perte est détectée. Le démarrage lent intervient d’une part pour les premières données émises sur une connexion et d’autre part lorsque aucune donnée n’a été transmise pendant un certain laps de temps (idle time) ou lorsqu’une perte est détectée. 

Impact sur un simple pingpong

Le pingpong est une application qui émet uniquement des données entre deux noeuds et ne fait pas de calcul. Le premier processus émet un message MPI qui est reçu par le destinataire puis retransmis vers l’émetteur. Elle est donc appropriée pour évaluer les communications MPI point à point. La courbe 4.4 a été obtenue grâce aux outils InstrAppli et tcp_probe (présentés en section 3.1.3) et présente le résultat d’un pingpong MPI effectué entre deux noeuds reliés par des liens avec 10.3 ms de latence. La bande passante du lien longue distance est de 1 Gbit/s et ne consitue pas un goulot d’étranglement. Dans cette expérience, la taille des données transférées est de 1 Mio et nous effectuons 100 aller-retours. Les croix représentent la taille des writes, la ligne rouge la taille de la fenêtre de congestion et la ligne verte la quantité de données dans le tampon d’envoi de TCP en fonction du temps. Jusqu’à 0.3 s, le message MPI est envoyé de l’émetteur vers le récepteur ; la fenêtre de congestion croît de manière exponentielle. Entre 0.3 et 0.6 s, le message est renvoyé dans l’autre sens, le tampon d’émission est à zéro. Un peu après 0.6 s on constate la première perte qui divise la fenêtre de congestion par deux et met fin au démarrage lent. On constate la grande 4.2. IMPACT DU CONTRÔLE DE CONGESTION DE TCP 73 0 200000 400000 600000 800000 1e+06 1.2e+06 1.4e+06 0 0.2 0.4 0.6 0.8 1 Taille (Octets) Temps (s) cwnd snd_buf write sizes Fig. 4.4 – Influence du démarrage lent sur l’émission de messages MPI de taille 1 Mio. différence entre le temps aller-retour du premier message (0.7 s) alors que le second met moins de 0.100 ms. Le démarrage lent est donc à éviter pour les applications MPI, qu’il soit dû à une période d’inactivité ou à une perte qui active fait expirer le délai de retransmission.

Impact du démarrage lent après une période d’inactivité

Le démarrage lent après une période d’inactivité est un mécanisme de TCP qui a pour but de re-tester le réseau lorsqu’on n’a pas communiqué sur une connexion pendant un certain temps. Ainsi, lorsque le délai d’inactivité sur un lien est écoulé, on redémarre lentement de manière à éviter d’introduire une quantité de données supérieure à ce que le réseau peut absorber dans son état actuel. Cet algorithme bénéficie à la fois aux flux déjà présents dans le réseau et aux flux qui recommencent à émettre car ils subissent tous moins de pertes. Cependant, comme nous l’avons observé dans la section 4.2.3.1, le mécanisme de démarrage lent est très coûteux pour les applications MPI. Afin de mettre en évidence le ralentissement induit par le démarrage lent après une période d’inactivité, nous avons exécuté les NPB entre deux grappes en désactivant ce mécanisme. La fenêtre de congestion reste donc à sa valeur précédente même après une période d’inactivité. Le débit du réseau longue distance est à 1 Gbit/s. La latence est de 18.1 ms. La figure 4.5(a) montre les temps d’exécutions des NPB sans démarrage lent relatif au cas avec démarrage lent après une période d’inactivité. Une valeur égale à 1 indique des performances équivalentes dans les deux alors qu’une valeur inférieure montre une amélioration des performances. On constate que BT, SP et dans une moindre mesure FT, bénéficient de la désactivation de l’algorithme (de l’ordre de 20% pour SP et BT). En effet, il est nécessaire que les applications communiquent peu souvent pour que le délai d’inactivité expire. Or, comme nous l’avons vu dans la section 3.1.4.3, seules BT, SP, FT et IS entrent dans cette catégorie. Ensuite, les communications ne doivent pas être synchrones sinon l’algorithme est utile : il permet de trouver le juste débit d’envoi afin d’éviter les pertes. De ce fait, IS est très affecté par la désactivation (plus de 40%). FT, par contre, améliore ses performances de 5% parce que l’algorithme de Alltoall implémenté dans MPICH2 fait en sorte de répartir l’envoi des données entre les processus, ce qui évite la congestion. 0 0.2 0.4 0.6 0.8 

Relative completion time bt cg ft is lu mg sp (a)

Sans trafic concurrent 0 0.2 0.4 0.6 0.8 1 1.2 bt ft is sp Temps d’execution relatif NPB Fichiers 1 + 2 (b) Avec transfert de fichier en parallèle Fig. 4.5 – Temps d’exécution des NPB en désactivant le démarrage lent après une période d’inactivité sur le temps sans le désactiver Cependant, la désactivation de ce mécanisme peut entrainer des pertes conséquentes sur les autres applications qui pourraient s’exécuter en parallèle. S’il est désactivé, après une période d’inactivité, une application MPI recommence à émettre avec un débit correspondant à la fenêtre de congestion de la dernière communication. Si elle n’est pas adaptée à la bande passante actuellement disponible sur le lien, ceci va entrainer des pertes pour les autres applications et contribuer à les ralentir. Afin d’évaluer l’impact de la désactivation de ce mécanisme sur les applications concurrentes, nous avons effectué deux transferts de fichiers en parallèle de l’application MPI (BT, FT, IS et SP). Un transfert est exécuté dans chaque sens de manière à utiliser totalement la bande passante du lien longue distance. Les fichiers font 40 Gio de manière à ce que leur temps de transfert soit du même ordre de grandeur que les temps d’exécution des applications concernées (excepté IS). La figure 4.5(b) présente le temps d’exécution des NPB qui peuvent bénéficier de la désactivation avec deux transferts de fichier en parallèle. Les valeurs représentent le temps avec désactivation du démarrage lent sur le temps avec ce mécanisme activé. A coté chaque NPB, nous présentons en vis-à-vis, la somme des temps de transfert des fichiers, pour lesquels le démarrage lent reste activé. On constate que les applications BT, FT et SP diminuent leur temps d’exécution lorsque que l’on désactive le démarrage lent (de 40%, 20% et 40%). Les temps de transferts de fichiers augmentent de l’ordre de 20% lorsque que les applications BT et SP sont exécutées en parallèle. Comme dans l’expérience précédente, IS est toujours impactée mais le temps de transfert des fichiers n’est pas significatif par rapport au temps d’exécution de l’application car il est grandement supérieur. Par contre, les transferts en parallèle de FT sont quasiement identiques dans les deux cas mais FT améliore ses performances de 20%. Ceci est dû au mode de communication de FT proche d’un envoi avec un flux continu. Ainsi, la désactivation peut entrainer des pertes de performances conséquentes sur les applications qui s’exécutent en parallèle des applications MPI. Cependant, l’impact de la désactivation est conséquent parce qu’il s’agit d’un transfert de fichier, une application MPI sera moins impactée parce qu’elle ne communique pas en continu. De plus, si on considère uniquement le temps d’exécution total (c’est à dire la somme des temps d’exécution des NPB et des transferts de fichiers), celui-ci est inférieur dans le cas sans démarrage lent. Ce cas est donc à préférer si on souhaite optimiser globalement les performances des applications de grille. 

Impact de la fenêtre de congestion

Comme nous l’avons présenté dans la section 4.2.1, le contrôle de congestion limite la quantité de données en vol sur une connexion. Bien que celle-ci soit nécessaire pour limiter la congestion, elle limite fortement les applications MPI. En effet, si elle n’est pas suffisamment grande le message sera envoyé en plusieurs fois. 0 200000 400000 600000 800000 1e+06 1.2e+06 1.65 1.7 1.75 1.8 1.85 Taille (Octets) Temps (s) cwnd snd_buf write sizes Fig. 4.6 – Délai introduit par la fenêtre de congestion dans l’envoi d’un message MPI. La figure 4.6 présente l’exécution d’un pingpong dans les mêmes conditions que dans la section 4.2.3.1 entre 1.65 s et 1.85 s. Sur le deuxième pic à 1.75 s, on constate un seuil sur le tampon d’émission. Celui-ci est dû au fait que le message n’est pas envoyé en une fois. En effet, la fenêtre de congestion bloque l’émission du message et ce n’est que lors du retour des ACKs que l’on peut envoyer la dernière partie. Le troisième pic à 1.8 s ne présente pas le même seuil. On constate également que le temps d’émission du message deux est plus longue que celle du message trois. 4.2.5 Performances des variantes de TCP avec les applications MPI Les sections précédentes ont montré que le contrôle de congestion ne pouvait être supprimé et que certaines applications pouvaient tirer parti d’une désactivation du démarrage lent après une période d’inactivité. Ce mécanisme, même s’il permet de déterminer la taille de la fenêtre de congestion initiale au démarrage de la phase d’évitement de congestion, ne constitue qu’une partie du contrôle de congestion. Nous allons donc nous intéresser à l’évolution de la fenêtre de congestion dans son ensemble (cf fig. 4.2). Nous cherchons à montrer comment celle-ci limite les émissions des messages MPI. Les sections suivantes présentent d’abord un état de l’art des différentes variantes de TCP disponibles pour les transferts de flux. Ces variantes tentent de résoudre différents problèmes 76 Variante de TCP α β TCP Reno 1 1/2 BIC-TCP 1 or bin.search 1/8 CUBIC cub(cwnd, history) 1/5 HighSpeed TCP inc(cwnd) decr(cwnd) H-TCP f(lastloss) 1 − RTTmin RTTmax Scalable-TCP 0.01 ∗ cwnd 1/8 TCP Illinois f(moy(RT T)) f(moy(RT T)) Tab. 4.1 – Constantes AIMD utilisées par certaines des variantes TCP [Gui09]. afférents à TCP en faisant évoluer la fenêtre de congestion différement. Ensuite, nous les évaluons dans le contexte particulier des communications MPI, qui communiquent plutôt de manière discontinue et par rafales. 4.2.5.1 Les différentes variantes de TCP Nous avons présenté dans la section 4.2.1, l’algorithme de TCP appelé New Reno [FHG04], dans lequel la fenêtre de congestion évolue selon un mécanisme appelé AIMD (Additive Increase Multiplicative Decrease). Différentes études comme [LM97] ont conclu que ce protocole arrivait difficilement à remplir la totalité d’un lien avec un grand produit débit*délai (bande passante * RTT). A la suite de ces recherches, différentes variantes de TCP ont été proposées parmi lesquelles on peut citer BIC [XHR04], CUBIC [RX05], Highspeed [Flo03], Hamilton TCP [SL04] (H-TCP), Scalable [Kel03]. Toutes ces variantes font évoluer différement la fenêtre de congestion en faisant varier les facteurs d’augmentation α et de diminution β (respectivement dans les équations 4.1 et 4.2 de la section 4.2.1). De ce fait, l’efficacité du protocole, l’équité par rapport aux flux dont le RTT est différent et l’équité par rapport aux autres variantes de TCP sont différentes. Le tableau 4.1 issu de la thèse de Romaric Guiller [Gui09] présente les valeurs des paramètres α et β de chacune des distributions disponibles. D’autres versions comme TCP Compound [TSZS06] ou TCP Illinois [LBS06] proposent d’utiliser également le délai de transmission comme indicateur de congestion. Lorsque le délai de transmission augmente, les paquets restent stockés dans la file d’envoi indiquant que le réseau n’est pas capable d’absorber tout les paquets. TCP Compound et Illinois différent cependant dans leur approche. TCP Compound se sert du délai de transmission pour déterminer une fenêtre de délai qui est ajoutée à la fenêtre de congestion habituelle. TCP Illinois quand à lui utilise les deux informations différement. Comme dans TCP NewReno, la réception d’un ACK va entraîner une augmentation de la fenêtre de congestion ou une diminution si une perte est détectée. Cependant les paramètres d’évolution α et β vont dépendre du délai de transmission. Malheureusement, TCP Compound n’est pas disponible dans les noyaux Linux actuels, elle n’a donc pu être testée. Nous avons donc évalué le comportement de ces variantes dans un environnement réel, sur la grille Grid5000. Notre première expérience a pour but d’obtenir l’évolution de la fenêtre de congestion. Les valeurs ont été obtenues avec le dispositif expérimental présenté par la figure 4.7 : deux noeuds réalisent l’émission des flux iperf depuis un site et une machine réalise la réception de ceux-ci sur un autre site. Le premier flux utilise TCP alors que le second, lancé au bout de 5 secondes utilise UDP avec un débit de 500 M bit/s. La latence était de 18 ms, la bande passante du WAN de 1 Gbit/s. Le flux UDP est nécessaire pour réduire le débit