Bonjour,
voila quelques news concernant sge et après quelques investigations, voila ce que j'ai compris :
-il existe différents "environnements", (qconf -spl, pour les lister et qconf -sp nom_env; pour voir les détails). mpich n'a rien à voir avec l'implémentation de mpi. Il s'agit d'un environnement qui distribue les calculs en parallèle sur chaque nœuds jusqu'à ce qu'il soit chargé complément.
qstat -t, bien pratique pour voir sur quel nœud/queue tournent les calculs (évite les tops)
j'ai pu lancer un job sur 32 noeuds (pour tester) mais, certains cas ne passaient pas. Le job était "running" mais rien ne se passait. J'ai constaté en regardant le fichiers
job.oID et job.poID que cela se produisait à chaque fois que cosinus était impliqué.
L'astuce que j'ai trouvé : rajouter -l hostname=matrics* pour ne lancer que sur les noeuds matrics001-016. Depuis plus de problème....
Benoit
ps : le pourcentage > 100 correspondaient bien à du calcul multi-threads (% proc utilisé par le processus). C'est ca qui faisait ramer le job. Ca fait une forme de court circuit avec mpi qui tente d'appliquer la règle de base étant 1 coeur / 1 processus. Enfin c'est ma compréhension du truc. Maintenant ca dépote.
ps2 : serait - il possible de "réparer" ganglia pour qu'on puisse visualiser l'activité des noeud 010 à 016 car ils ne sont pas actualisés.
voila quelques news concernant sge et après quelques investigations, voila ce que j'ai compris :
-il existe différents "environnements", (qconf -spl, pour les lister et qconf -sp nom_env; pour voir les détails). mpich n'a rien à voir avec l'implémentation de mpi. Il s'agit d'un environnement qui distribue les calculs en parallèle sur chaque nœuds jusqu'à ce qu'il soit chargé complément.
qstat -t, bien pratique pour voir sur quel nœud/queue tournent les calculs (évite les tops)
j'ai pu lancer un job sur 32 noeuds (pour tester) mais, certains cas ne passaient pas. Le job était "running" mais rien ne se passait. J'ai constaté en regardant le fichiers
job.oID et job.poID que cela se produisait à chaque fois que cosinus était impliqué.
L'astuce que j'ai trouvé : rajouter -l hostname=matrics* pour ne lancer que sur les noeuds matrics001-016. Depuis plus de problème....
Benoit
ps : le pourcentage > 100 correspondaient bien à du calcul multi-threads (% proc utilisé par le processus). C'est ca qui faisait ramer le job. Ca fait une forme de court circuit avec mpi qui tente d'appliquer la règle de base étant 1 coeur / 1 processus. Enfin c'est ma compréhension du truc. Maintenant ca dépote.
ps2 : serait - il possible de "réparer" ganglia pour qu'on puisse visualiser l'activité des noeud 010 à 016 car ils ne sont pas actualisés.
Aucun commentaire:
Enregistrer un commentaire