[Mpi3-ft] Transactional Messages

Richard Graham rlgraham at ornl.gov
Sat Feb 23 08:38:51 CST 2008


So I think we are some what talking past each other.  I think that what you
really care about
 with respect to communications errors is information on messages that have
not completed,
 and, more important, can¹t complete ?  Is this correct ?
I have focused more on errors that occur, but the low-level can handle them
and does not need
 to pass information about them back up to the user.  I believe this is
where we said that we
 may want to be able to give the app some indication on performance
degradation, at their
 request.  Is this correct ?

Rich


On 2/23/08 8:47 AM, "Greg Bronevetsky" <bronevetsky1 at llnl.gov> wrote:

>>>> >> There is not new API, would just need to pass some sort of parameter to
>>>> MPI_Init().  This
>>>> >>  is not the only place this is needed.  If you want to take a look at
>>>> the implementation, take
>>>> >> a loot at http:// <http://public.lanl.gov/lampi> public.lanl.gov/lampi
>>>> <http://public.lanl.gov/lampi>
>> 
> 
> Right, LAMPI! Yeah, its not a transactional API but rather a more reliable
> implementation of MPI. This is also good but its probably not something
> related to transactional messages since the transactional messages API is
> meant to define how message errors are exported to the application. LAMPI and
> similar stuff would be more related to a QoS API that allows the application
> to trade off performance for reliability.
> 
> Greg Bronevetsky
> Post-Doctoral Researcher
> 1028 Building 451
> Lawrence Livermore National Lab
> (925) 424-5756
> bronevetsky1 at llnl.gov
> 
> _______________________________________________
> Mpi3-ft mailing list
> Mpi3-ft at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-ft/attachments/20080223/20181325/attachment-0001.html>


More information about the mpiwg-ft mailing list