Conceptual and Akypuera

Table of Contents

Sitemap

---> misc
| ---> 2016
| ---> 2015
| ---> 2014
| ---> 2013
| ---> 2012
`--> Agenda

SkaMPI is somehow limited for what we want to do (e.g. performing p2p message modeling while there is another pair of process heavily communicating, or not synchronizing between each call to measure_*). Martin remembered of Conceptual so we gave it a try and the tool is actually quite impressive. When coupled with akypuera and paje, we can see exactly what we want.

Paje

Installation facile à partir de http://paje.sourceforge.net/documentation.html

Conceptual

  make stylesheets
  cp ncptl-mode.el* ~/lib/elisp/
  echo "(add-to-list 'load-path \"~/lib/elisp\")" >> ~/.emacs
  echo "(require 'ncptl-mode)" >> ~/.emacs

Akypuera

  export https_proxy="http://proxy:3128"
  export http_proxy="http://proxy:3128"
  git clone https://github.com/schnorr/akypuera.git

puis suivre les instructions du INSTALL 

  export LD_LIBRARY_PATH=$HOME/lib:$LD_LIBRARY_PATH #if needed
  mpicc source_file.o -o mpi_app -laky
  rastro_timesync `cat machine_file` > toto
  mpirun ... mpi_app
  rastro_timesync `cat machine_file` >> toto
  aky_converter --sync=toto *.rst > foo.trace

Conceptual + Akypuera

Voici la capture Paje de 5 traces obtenues avec Conceptual + Akypuera et visualisées avec Paje. Attention, on n'a pas forcément fait attention à ce que les échelles de temps soient les mêmes dans toutes les traces… screenshot_2012-01-24_23:37:59.png

20 ping(32); 1 pong(32)

  • à l'oeil, le temps du pong est du même ordre de grandeur que celui du pong donc a priori pas de problème de drift ou de synchro

  • mpi/tcp semble agréger les messages:

    • un temps à peu près constant est pris à l'émission.
    • la première réception coûte cher car le récepteur rentre

    dans le Receive et attends. Les suivantes sont gratuites car la donnée est déjà là.

  • l'asynchronisme crée un décalage entre l'émetteur et le récepteur (les flèches sont de plus en plus penchées)
  • Si on pousse un peu ce scénario, que voit-on ?

200 ping(32) ; 50 pong(32)

  • On a encore une agrégation mais elle semble "erratique".
  • Si on compare avec les précédentes, il est curieux de constater que les 20 premiers pings étaient agrégés alors que là, il y en a plutôt moins. C'est peut-être dû à la barrière qui fait que le récepteur a mis du temps à poster les receive, ce qui fait que les flèches donnent l'impression que tout le monde a été agrégé.
  • On pourrait modéliser ce genre de chose en étudiant le nombre de messages agrégés et en regardant sa distribution. Après, on tirerait lors du premier send quand il va effectivement partir sur le réseau et tous les message arrivant avant seraient agrégés.
  • La flèche la moins penchée nous donne l'information sur la "vraie" latence, i.e. le temps de propagation minimal. Une fois que le message est en train de partir, il y a potentiellement le même problème à la réception. Parfois, le récepteur met un certain temps à être prévenu que le message est là. Par contre, pour des messages agrégés, la réception est instantanée.

200 ping(32Kb) ; 50 pong(32Kb)

Il y a aggrégation en émission et les réceptions sont plutôt régulières.

200(ping(32) ; PING(320)) ; 50(pong(32))

On alterne gros et petit et les agrégations ont l'air bizarre. À refaire.

200 ping(32) ; 50 pong(32) en openib

Là, c'est super régulier, pas d'agrégation. On a l'impression qu'il y a des synchros mais c'est dû à des problèmes de résolution d'horloge. Pour les petits messages, IB est plutôt cool pour l'instant.

Une idée de modèle suite aux longues discussions avec Mt

Phénomènes importants (hypothèses à tester):

  • Gros messages = steady-state (linéaire)
  • Petits messages = constant + bruit (heavy-tail)
  • Moyens = bizarre (droit en log log).
  • Séparation du traitement des gros messages (en steady state dans lmm) et des petits messages (uniquement en délai) avec donc aucune interférence entre ces deux types de messages (ni dans un sens, ni dans l'autre).
  • Agrégation sender-side des petits messages (bufferisation et envoie effectif sur buffer plein ou timeout). On a un o_s^aggreg d'aggrégation (très faible mais plus gros qu'un bête memcopy. syscall ?) où on réécrit dans le buffer et un autre (o_s^bufferflush), bien plus important et variable. Tout se passe comme si l'émission supplémentaire attendait que le buffer soit intégralement flushé avant de pouvoir continuer.

  • "Agrégation" receiver-side. Si on regarde quand le message est sensé partir de l'émetteur (le dernier agrégé en émission) et qu'on rajoute la latence (i.e. min(le temps écoulé entre la sortie du send du dernier train de paquets et l'entrée dans le receive du premier paquet du train)), il y a souvent un temps important avant la fin de la réception correspondante. Tout se passe comme si le récepteur était prévenu trop tard que les informations sont disponibles.

    Il y aurait donc un o_r^memcopy (très très petit) pour quand les données sont déjà arrivées dans openMPI, et un o_r^OS (dû au noyau, à MPI, à TCP, à une interruption matérielle, … peut être plusieurs choses différentes) beaucoup plus important et variable que le précédent. On pourrait l'expliquer par (speculations inside):

    • un appel système à tous les coups
    • si les données sont dans le kernel, l'appel système retourne

    tout de suite mais c'est quand même le coup d'un appel système

    • sinon, le process est déschédulé et mis en attente de

    l'interruption matérielle. Il sera prévenu à la fin d'un quantum de temps.

    • Dans l'idéal, on aimerait modéliser le o_r et le o_s en fonction de la taille du message (avec un modèle en fonction de l'intervalle dans le quel on se trouve et que se modèle soit simple en fonction de la taille).

Choses à faire dans Akypuera

  • Rajouter l'information de la taille de message
  • Je peux facilement faire grep pour avoir les temps passés à faire les receive ou les sends mais pour calculer les temps de communication (sur le réseau), il me faut accéder aux flèches, voire les clusteriser…
  • Comment faire pour que Paje ne plante pas aussi régulièrement ?

Entered on [2012-01-24 mar. 16:43]