<HTML>
<HEAD>
<TITLE>Re: [mpi3-ft] FW: Starting slides for 2/1/2008 telecon</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
<BR>
<BR>
On 1/30/08 4:40 AM, "Thomas Herault" <thomas.herault@lri.fr> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
<BR>
Le 30 janv. 08 à 09:17, Greg Bronevetsky a écrit :<BR>
<BR>
> Two comments:<BR>
><BR>
> We may want to add the capability to spawn new processes and give<BR>
> them the ranks of the failed processes. This is more efficient than<BR>
> pre-allocating enough spare processes as part of the original job<BR>
> allocation, so it might be a good idea to include in the spec.<BR>
><BR>
<BR>
A user should be able to spawn new processes and create a new<BR>
communicator with enough processes to circumvent this issue.<BR>
<BR>
I think that size of MPI_COMM_WORLD should decrease<BR>
when failures occur. Not all fault tolerance solutions need processor<BR>
replacement (e.g. a master/worker approach when a worker fails).<BR>
But MPI_UNIVERSE_SIZE should be allowed to remain constant<BR>
(thus, the system can provide dynamically new processors to<BR>
replace failed ones).<BR>
<BR>
>> No disagreements. As I mentioned earlier, we need to start with the<BR>
>> non-trivial amount of work that has already been done in this area. At<BR>
>> this stage I am deliberately staying away from trying to propose specific<BR>
>> solutions – we need to first define what we think we can address, and<BR>
>> what we will just pass on.<BR>
<BR>
> I disagree with the comments about MPI quieting the communication<BR>
> system because this presumes that the application will use the<BR>
> trivial sync-and-stop CPR protocol. They may the case but we<BR>
> shouldn't write this assumption into the spec. We should probably<BR>
> restrict ourselves to only saying that no message may get partially<BR>
> delivered since such messages would be very hard to deal with above<BR>
> the MPI library.<BR>
><BR>
<BR>
I agree that we should not assume that synchronized CPR will be the<BR>
only approach used. Messages must certainly be kept transactional<BR>
(either completely received or not at all). But what about collective<BR>
communications? As suggested during the meeting, a two-phase commit<BR>
protocol can be enforced to ensure that any collective communication<BR>
either completes or fails on any living processor; however this may be<BR>
considered as too inefficient for the normal case, when failures do not<BR>
occur.<BR>
<BR>
>> No assumption on solution is being made. At this stage I believe that the<BR>
>> primitives listed will cover the current solutions people have deployed.<BR>
>> The intent is to provide as set of tools that can be used as needed – i.e.<BR>
>> the standard should not be advocating a solution, but enabling solutions<BR>
>> that don’t involve modifying every MPI implementation (if possible). If there<BR>
>> are missing primitives, please bring them up. If there are primitives listed<BR>
>> that are not needed, please mention these too.<BR>
<BR>
Rich<BR>
<BR>
Thomas Herault<BR>
assistant professor<BR>
INRIA/Univ. Paris Sud<BR>
<BR>
> Greg Bronevetsky<BR>
> Post-Doctoral Researcher<BR>
> 1028 Building 451<BR>
> Lawrence Livermore National Lab<BR>
> (925) 424-5756<BR>
> bronevetsky1@llnl.gov<BR>
><BR>
> At 10:12 AM 1/29/2008, Richard Graham wrote:<BR>
>> This did not seem to make it through the first time, so let me try <BR>
>> again.<BR>
>><BR>
>> Rich<BR>
>><BR>
>> ------ Forwarded Message<BR>
>> From: Richard Graham <rlgraham@ornl.gov><BR>
>> Date: Tue, 29 Jan 2008 10:55:11 -0500<BR>
>> To: Discussion of MPI 3 Fault Tolerance Support <mpi3-ft@cs.uiuc.edu><BR>
>> Conversation: Starting slides for 2/1/2008 telecon<BR>
>> Subject: Starting slides for 2/1/2008 telecon<BR>
>><BR>
>> Attached is a set of slides I intend to use as a staring point for <BR>
>> the<BR>
>> telecon this coming Friday. If you are planning on attending, <BR>
>> please take a<BR>
>> look at these, and see what is missing. The main goal for this <BR>
>> call is to<BR>
>> help set the scope of the problem for which we intend to propose <BR>
>> changes to<BR>
>> the MPI standard.<BR>
>><BR>
>> Thanks,<BR>
>> Rich<BR>
>><BR>
>> ------ End of Forwarded Message<BR>
>><BR>
>><BR>
>><BR>
>> _______________________________________________<BR>
>> mpi3-ft mailing list<BR>
>> mpi3-ft@cs.uiuc.edu<BR>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi3-ft">http://lists.cs.uiuc.edu/mailman/listinfo/mpi3-ft</a><BR>
> _______________________________________________<BR>
> mpi3-ft mailing list<BR>
> mpi3-ft@cs.uiuc.edu<BR>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi3-ft">http://lists.cs.uiuc.edu/mailman/listinfo/mpi3-ft</a><BR>
<BR>
<BR>
_______________________________________________<BR>
mpi3-ft mailing list<BR>
mpi3-ft@cs.uiuc.edu<BR>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi3-ft">http://lists.cs.uiuc.edu/mailman/listinfo/mpi3-ft</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
</SPAN></FONT>
</BODY>
</HTML>