[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