[gull] MPICH - packets sniffing

Daniel Cordey dc at mjt.ch
Fri May 27 11:07:02 CEST 2005


On Friday 27 May 2005 00:23, Farid Moussaoui wrote:

> Il n'est pas necessaire (et souhaitable) de faire des "profilers" a
> l'interieur des
> routines MPI. C'est un standard de commication pour la programmation
> parallele.

Il n'est pas question de modifier quoi que se soit au niveau du protocole... 
mais d'inclure des fonctionalites de logging qui pourrons etre analysees par 
la suite ou en temps-reels (mais ca c'est plus complexe). Le but de cette 
approche est justement de ne pas toucher a l'application existante.

Or, quand je vois sur le site de TAU :

	Adding TAU Profiling API calls to your code

... je comprends que TAU doit <obligatoirement> s'inserer dans le code.

Si cette approche permet de faire un certain type de mesure, il necessite de 
modifier le code source. Ce n'est parfois, ni souhaitable, ni a la portee de 
n'importe qui. Modifier le code source d'une grosse application // de calcul 
par elements finis ne me semble pas trivial ni meme simple. 

> Su vous travaillez sur les systemes paralleles de SGI., il y a ProDev
> WorkShop qui collecte les performances des differentes parties du code.

Encore, on parle de "profiling" sur des parties de code, alors que la plupart 
du temps on desire une vision de la maniere dont le code est "reparti" ainsi 
que l'impact de cette repartition, lie aux performances du reseau et aux 
differents systemes auxquels les taches sont confiees. En general, on sait 
comment une application reparti son travail, mais on desire mesurer l'impact 
de la partie "overhead" due aux performces du reseau, etc.

Tres souvent, on effectue ce gener de mesure pour determiner la maniere dont 
on doit architecturer son infrastructure. On cherche les goulets 
d'etrangelemnt, pas le nom de la fonction de calcul qui devrait etre recrit 
en assembleur pour gagner 5% de temps de calcul. TAU me semble tres approprie 
pour obtenir une granularite de donnee tres poussee, mais il implique surtout 
la modification du code source. 

L'objet de la question concernant principalement la mesure de la charge 
reseau. Les autres points de la question peuvent etre resolus avec 
iostat/vmstat sur chacun des noeuds et ne semblent pas etre l'objet de la 
question principale. Or, la charge reseau ne peut mieux se mesurer qu'en 
etant le plus proche possible des emissions/sources des paquets echanges. 
D'ou ma suggestion de "logguer" les paquest au niveau MPI; sans toucher a 
l'application.

DOnc, pas de modification du kernel, ni de l'applicatifs. D eplus, ces 
fonctionalites suplementaires peuvent parfaitement etre utilisees pour mesure 
les performances d'aurtres applications (dont on a peut-etre pas le code 
source).

dc





More information about the gull mailing list