<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Rich,<br>
<br>
If, as part of ft mpi, some piggy-back support is provided to the
application,<br>
then i don't think this behavior would need to be implemented in the<br>
mpi library.<br>
<br>
Howard<br>
<br>
Richard Graham wrote:
<blockquote cite="mid:C525E69B.26E79%25rlgraham@ornl.gov" type="cite">
<title>Re: [Mpi3-ft] Summary of today's meeting</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Can someone think of a reason to have the
library do this over the app ? I can see that letting the library do
this will avoid potential race conditions that could arise if we let
the app do this - basically out of band with respect to the expected
communications traffic.<br>
<br>
Rich<br>
<br>
<br>
On 10/21/08 11:52 PM, "Thomas Herault" <<a moz-do-not-send="true"
href="herault.thomas@gmail.com">herault.thomas@gmail.com</a>> wrote:<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
<br>
Le 21 oct. 08 à 22:06, Howard Pritchard a écrit :<br>
<br>
> Hello Rich,<br>
><br>
> I thought it was also agreed that if process A communicates with <br>
> failed process B<br>
> which had been restarted by another process C, and this was the <br>
> first communication<br>
> from A to B since the restart of B, A would receive the equivalent
<br>
> of a ECONNRESET error.<br>
> This was in the context of a case where option 5 below is not
being <br>
> used by the app.<br>
><br>
> Howard<br>
><br>
<br>
Hello Howard,<br>
<br>
there was still some discussions about this at the end of the session.<br>
<br>
The argument is that the application could do as well as the library <br>
to enforce this detection if this is needed: when a process is <br>
launched to replace another one, it could define a new revision/epoch/<br>
restart number and tag each communication with this number to <br>
implement the check. If this can be done as efficiently by the <br>
application as it would be done by the library, asking the application <br>
to do it itself would help the library to avoid the additional cost <br>
(i.e. piggybacking an integer to each message) when the application <br>
does not need that functionality.<br>
<br>
It was suggested that the library could provide a generic mean to <br>
piggyback this kind of information to each message, in a way similar <br>
as what is discussed about piggyback/message logging-based fault <br>
tolerance.<br>
<br>
Thomas<br>
<br>
> Richard Graham wrote:<br>
>><br>
>> Here is a summary of what I think that we agreed to today.
Please <br>
>> correct any errors, and add what I am missing.<br>
>><br>
>> • We need to be able to restore MPI_COMM_WORLD (and it’s <br>
>> derivatives) to a usable state when a process fails.<br>
>> • Restoration may involve having MPI_PROC_NULL replace
the lost <br>
>> process, or may replaced the lost processes with a new process
<br>
>> (have not specified how this would happen)<br>
>> • Processes communicating directly with the failed
processes will <br>
>> be notified via a returned error code about the failure.<br>
>> • When a process is notified of the failure,
comm_repair() must be <br>
>> called. Comm_repair() is not a collective call, and is what
will <br>
>> initiate the communicator repair associated with the failed
process.<br>
>> • If a process wants to be notified of process failure
even if it <br>
>> is not communicating directly with this process, it must
register <br>
>> for this notification.<br>
>> • We don’t have enough information to know how to
continue with <br>
>> support for checkpoint/restart.<br>
>> • We need to discuss what needs to do with respect to
failure of <br>
>> collective communications.<br>
>><br>
>> There are several issues that came up with respect to these,
which <br>
>> will be detailed later on.<br>
>><br>
>> Rich<br>
>><br>
>> _______________________________________________<br>
>> mpi3-ft mailing list<br>
>> <a moz-do-not-send="true" href="mpi3-ft@lists.mpi-forum.org">mpi3-ft@lists.mpi-forum.org</a><br>
>> <a moz-do-not-send="true"
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</a><br>
>><br>
><br>
><br>
> --<br>
><br>
> Howard Pritchard<br>
> Cray Inc.<br>
><br>
> _______________________________________________<br>
> mpi3-ft mailing list<br>
> <a moz-do-not-send="true" href="mpi3-ft@lists.mpi-forum.org">mpi3-ft@lists.mpi-forum.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</a><br>
<br>
<br>
_______________________________________________<br>
mpi3-ft mailing list<br>
<a moz-do-not-send="true" href="mpi3-ft@lists.mpi-forum.org">mpi3-ft@lists.mpi-forum.org</a><br>
<a moz-do-not-send="true"
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</a><br>
<br>
</span></font></blockquote>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
mpi3-ft mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpi3-ft@lists.mpi-forum.org">mpi3-ft@lists.mpi-forum.org</a>
<a class="moz-txt-link-freetext" href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Howard Pritchard
Cray Inc.
</pre>
</body>
</html>