Designed experiments to perform for SMPI modeling

Le temps de communication n'est pas linéaire en fonction de la taille des messages. Essayer de le caractériser.

1. Envoi de N messages de taille 10^x avec x dans U(0,7).
2. Analyse pour détecter des intervalles de tailles de messages où on arrive à caractériser et poser un modèle
3. En déduire les XP qui permettent d'instancier les modèles.

Résultat attendu: trois intervalles. Presque constant sur le premier avec caractérisation du bruit, x^0.7 sur le second et affine sur le troisième.

A et C sont sur la même machine. B et D sur une autre machine. Expérience Zoo entre A et B pendant un Jumbo send entre C et D.

Résultat attendu:

• elephant sur mices: ??
• elephant sur cats: ??
• elephant sur elephant: moitié moitié.
• Variante du test: tester le switch avec A, B, C et D sont sur 4 machines distinctes. On espère aucune interference.

1. Qu'est-ce qui déclanche l'envoi effectif ?
   • timeout ?
     • on envoie des séries de 2 bytes (pour pas se faire avoir par le buffer plein)
     • on intercalle des micro-sleep entre les sends pour essayer de détecter à partir de quand il envoie automatiquement
   • buffer plein ?
     • on envoie de plus en plus gros jusqu'à ce qu'il n'y ait plus d'aggrégation
2. Caractériser le temps du flush du buffer côté sender.
3. La latence "physique" Quel est le temps minimum pour transmettre le message
4. Caractériser l'aggrégation et l'overhead de réception.

L'expérience de base est un (ping S; sleep T)*. S in {2,200,2000} et T (0,une latence, 10 latences).

1. On détecte les bursts, i.e. la quantité de paquets aggrégés par l'émetteur. On dira que des paquets sont aggrégés s'ils ont été envoyés à peu d'écart (genre un syscall) et reçus à très très très peu d'écart (genre 0 ou un memcopy).
2. On considère les temps d'émission. Il y a beaucoup de "petits" (0 à 5E-6 sur les données qu'on a regardées) et quelques plus gros. On les sépare (avec l'histogramme) et on essaye de les caractériser. Les petits (o_s^aggreg) correspondraient à un syscall. Les plus gros correspondraient à un bufferflush (o_s^bufferflush).
3. Un min un peu compliqué mais ça doit se faire. D'habitude, les gens font un (ping(0); pong(0))* et prennent le min/2.
4. o_r^memcopy se voit très bien en faisant un histogramme en échelle log car les ordres de grandeur sont très différents. Ensuite, on les vire et on regarde ceux qui restent pour caractériser o_r^OS. Notre première impression, c'est qu'ils sont indépendants et avec une distrib un peu heavy tail. On a d'abord pensé (suite à la visu Paje) à mettre en place une discrétisation (quantum de scheduling) mais rien de tel dans

On espère que ces différents paramètres (o_s/o_r) ont le bon goût de ne pas trop dépendre de S et T.

Comme avec les souris mais en Paje pour poser des hypothèses.

Expérience à inventer quand on en saura plus sur la précédente. Peut-être 2 Zoo en concurrence. Peut-être besoin de rajouter des sleep variables entre chaque send pour regarder l'impact de la charge. À voir…

Entered on [2012-01-26 jeu. 21:06]