Hi Yann, I believe the largest system we ran the mpd ring on was around 4800 hosts at NCSA. We still use it and it is still a ring, although we are in the process of designing another process manager, and a new version of PMI that will work better with existing process managers like SLURM, SGE, etc. We remain interested in this area of MPI implementation. I look forward to meeting you in January. Regards, Rusty Lusk On Dec 18, 2007, at 10:01 AM, Yann K. wrote:

Mister Lusk,

I present myself briefly. I'm working for Bull, a hardware and software business company, which deals HPC machines (www.bull.com/hpc). I'm a technical responsible of the parallel computing departement. We do a mpi library, based on MPICH2, and a lot around mpi as well. I've seen you in Europvm this year and had not the issues I have today with some of the software you might be dealing with, especially the mpd launching subsystem. I have currently two questions for you if you have time to answer:

+ how scalable is the mpd subsystem (>=1.90) on a huge machine ? What's the biggest configuration you've seen working with it ? I have doubt on its ring scalability (perhaps it changed its algorithm since I last checked mpd).

+ PMI is one of the greatest thing invented after MPI in the domain and unfortunately not a lot of people realize how it could help them get more flexibility in their system if all resource manager where speaking the PMI protocol. This one got out of the SciDac SSS work if I remember. When I talk to Al Geist, and asked about how those SSS interfaces did not get more attention, he was not able to answer. I have proposed to review chapter 5 as well for MPI, and especially the 5.2, where a lot of fog remains. I saw you were reviewing this as well. I've been promoting PMI for years *2 now :) even to OpenMPI guys who didn't know about it)*. I like to think there is place for more descriptions of the MPI external interactions, especially with upper layers systems.

I'll be in Chicago at the MPI2.2/3.0 meetings.

Thanks for your time

Yann K.