[Mpi3-ft] FT Working Group Teleconf (today)
Richard Treumann
treumann at us.ibm.com
Wed Mar 24 09:13:25 CDT 2010
I just took a look at the piggy back proposal. I do not see a fundamental
problem but there are a couple points worth a mention
1) Mandating extra fields in a status object breaks binary compatibility.
An MPI library that assume it is filling in new form status when the
application was compiled with old form status will trash some other part of
memory. When a status was determined to be a user allocated structure in
MPI 1.0, the ability to change it was forfeited.
2) Expecting libmpi to recognize that the piggyback sent was bigger than
the piggyback expected and truncate the piggyback while delivering an
intact user message is not going to be practical. The MPI standard should
treat this exactly the way it treats any send/recv in which type signatures
do not match. I.E. if total bytes sent is <= total expected, the outcome is
undefined and if total bytes sent is > total expected it is an error and
the resulting buffer content is undefined. The standard only obliges libmpi
to refrain from trashing memory outside the footprint of the typemap.
IBM uses an approach that distributes inbound packets (which may arrive out
of order) directly into the receive type map. If the bytes coming in >
expected we discard all packets and if <=, we put the bytes wherever the
recv side typemap says and have no way of knowing the send type signature
and recv type signature are inconsistent. Adding metadata to validate send
type signature against recv type signature would be too expensive
.
Dick Treumann - MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
From: George Bosilca <bosilca at eecs.utk.edu>
To: "MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <mpi3-ft at lists.mpi-forum.org>
Date: 03/24/2010 09:35 AM
Subject: Re: [Mpi3-ft] FT Working Group Teleconf (today)
Sent by: mpi3-ft-bounces at lists.mpi-forum.org
Josh,
I will not be able to attend either, we have a hard deadline this
afternoon.
I did not have time to gather new results regarding the datatype
manipulations for piggybacking techniques, so my position didn't change
from the last Forum meeting. As a reminder, with few optimizations in the
MPI library the whole datatype cycle (creation, commit and free) is under a
micro-second (to be exact 0.86 on a 2Ghz Intel machine). This has been done
without any caching implemented at the application level.
Thanks,
george.
On Mar 24, 2010, at 09:27 , Josh Hursey wrote:
> Reminder that we have a teleconf today, Wed 3/24/2010, at 12 noon EDT.
>
> Date: March 24, 2010
> Time: 12 noon EDT/New York
> Dial-in information:
> 877-801-8130
> Code: 1044056
>
> Agenda:
> - Piggybacking (Greg B., George B., Darius B)
> - Async. process management (Josh H.)
> - other items?
>
> Respond to the list if you have any additional topics that you wish to
cover.
>
> Rich will not be bale to attend today, so I am covering the call setup.
>
> -- Josh
>
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
_______________________________________________
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/20100324/98e87ba6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-ft/attachments/20100324/98e87ba6/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-ft/attachments/20100324/98e87ba6/attachment-0003.gif>
More information about the mpiwg-ft
mailing list