[Mpi3-ft] fault-tolerant collectives

[Graham, Richard L.]

  I have been talking a reasonable amount with apps folks lately about this proposal, and they first response is often one of shock, as it is not quite what folks initially expect.  However, once one explains the background for the proposal, people tend to accept the notions.
  I agree that we need to define a mechanism for specifying return codes - uniform among surviving ranks, or locally determined types.  However, I do believe that we need to add the second set of collectives into 3.0.  We have mentioned this as an option for several years (actually since the inception of the group almost 4 years ago), but as a working group never did something explicit about this.  There is a reasonable number of apps folks that expect this type of collective communications.
  One other thing that came up yesterday (I have given 2 talks about the FT stuff in Kobe this week) is that it would be good to be able to specify multiple communicators to mpi_comm_validate(), especially, since a common motif is to dup an existing communicator to isolate communication.  This is really the only way that I can think of to avoid un-needed global communication, if more than one communicator is of interest to the app.

Rich

-----Original Message-----
From: mpi3-ft-bounces at lists.mpi-forum.org [mailto:mpi3-ft-bounces at lists.mpi-forum.org] On Behalf Of Darius Buntinas
Sent: Friday, September 09, 2011 4:39 PM
To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group
Subject: Re: [Mpi3-ft] fault-tolerant collectives


OK, that makes sense.  I'll fix up that text.

Thanks,
-d

On Sep 9, 2011, at 3:36 PM, Josh Hursey wrote:

> I think that we want to say that an implementation may provide uniform
> return codes from collectives, but are not required to do so. So this
> makes then fault tolerant-ish - in the sense that they have to work
> around failure to return error codes consistently, but not that they
> finish the collective successfully even if new process failures emerge
> during the collectives (that would undermine the semantic protections
> we are putting in place).
> 
> We should probably not say 'fault tolerant collectives' in the current
> proposal so we don't confuse things. Maybe 'collectives that provide
> uniform return codes'?
> 
> 
> If we want truly fault tolerant collectives (like those described
> below), then I think we should introduce a different set of functions.
> The functions should probably return a group of processes that either
> did or did not participate in creating the final result. Something
> like:
>  MPI_Reduce_ft(..., &group);
> 
> I think the true fault tolerant collectives should be left to a follow
> on ticket since there is a need, but can be easily added as a second
> step.
> 
> -- Josh
> 
> On Fri, Sep 9, 2011 at 4:17 PM, Darius Buntinas <buntinas at mcs.anl.gov> wrote:
>> 
>> We discussed the option of allowing an implementation to provide fault tolerant (not just fault-aware) collectives.  The idea is that even when a process fails, collectives will continue to operate correctly (modulo the failed process).
>> 
>> Does this imply that the communicator will never become collectively inactive?
>> 
>> If no, then what's the point of ft collectives?
>> 
>> If yes, then the application may never get notification that a process has failed and collectives are now running one short.  Is this what we really want?
>> 
>> -d
>> _______________________________________________
>> mpi3-ft mailing list
>> mpi3-ft at lists.mpi-forum.org
>> hxxp://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>> 
>> 
> 
> 
> 
> -- 
> Joshua Hursey
> Postdoctoral Research Associate
> Oak Ridge National Laboratory
> hxxp://users.nccs.gov/~jjhursey
> 
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft at lists.mpi-forum.org
> hxxp://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft


_______________________________________________
mpi3-ft mailing list
mpi3-ft at lists.mpi-forum.org
hxxp://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft