February 2008 - mpiwg-ft - mailman3.cels.anl.gov

Re: [Mpi3-ft] Transactional Messages
by Greg Bronevetsky 23 Feb '08

23 Feb '08

>Just to follow up, I think that the right >thing to do with respect to some sort of > transactional model is to have some sort of standard way to request such > communications take place probably at init time. We have had such an MPI > implementation running in production for several years on a multi-thousand > process cluster, and the only thing that needs > to be exposed to the users is the > ability to turn on/off the functionality > all the rest is taken care of just fine within > the context of the MPI 2.0 standard, and is 100% standard compliant. Cool! Can you post the API for this thing? Might be a useful thing to start from. Also, its a prototype implementation. >This does not deal with hints on the network state. Yeah, I'm not sure if such hints are valuable enough to be included in the spec. It really falls under the quality-of-service ideas what we've tossed around, so we should write up a proposal for those and see how much QoS people really want. Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 bronevetsky1(a)llnl.gov

1 0

Re: [Mpi3-ft] Transactional Messages
by Richard Graham 22 Feb '08

22 Feb '08

Just to follow up, I think that the ³right² thing to do with respect to some sort of transactional model is to have some sort of standard way to request such communications take place probably at init time. We have had such an MPI implementation running in production for several years on a multi-thousand process cluster, and the only thing that needs to be exposed to the users is the ability to turn on/off the functionality all the rest is taken care of just fine within the context of the MPI 2.0 standard, and is 100% standard compliant. This does not deal with hints on the network ³state². Rich On 2/22/08 10:22 PM, "Greg Bronevetsky" <bronevetsky1(a)llnl.gov> wrote: > > >> >I've read the Transactional Messages proposal and I am a ittle confused >> >here. Is there a reason why we believe that message faults themselves >> >should be handled by the application layer instead of the MPI library? >> >Using the latter model allows one to reduce the error conditions >> >perculated up to the user to revolve around loss of the actual >> >connection to a process (or the actual process itself). > > Actually, one aspect of the proposal is that I made sure not to > define message faults at a low level. They may be any low-level > problems that the implementation cannot efficiently deal with on its > own and that are best represented to the application as message > drops. One example of this may be process failures. Although we will > probably want to define a special notification mechanism to expose > those failures to the application, we will also need a way to expose > the failures of any communication that involves the process. Another > example may be simplified MPI implementations that do not have > facilities for resending messages because the probability of an error > is rather low and performance is too important. In fact, applications > that can tolerate message drops may explicitly choose those MPI > implementations for the performance gains. > > Greg Bronevetsky > Post-Doctoral Researcher > 1028 Building 451 > Lawrence Livermore National Lab > (925) 424-5756 > bronevetsky1(a)llnl.gov > _______________________________________________ > Mpi3-ft mailing list > Mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >

1 0

Re: [Mpi3-ft] Transactional Messages
by Richard Graham 22 Feb '08

22 Feb '08

Actually, it is most likely that MPI implementations that don¹t try to deal with dropped messages, can¹t even detect that such event have occurred. For such implementation I would expect them to be able to detect a problem with failed communications only if the low-level library they use to implement the communications, such as some OS bypass library, returns an error when trying to post some sort of communications, or if the run-time used by MPI detects a fail process, and propagates this information to the rest of the processes in the application. The ONLY layer that can handle any sort of recovery from a live communications failure - i.e. w/o some sort of check-point restart with or with out message logging is the MPI implementation itself. The application reposting a send can¹t take get around the lost data, because of the MPI message ordering requirements, unless the implementation totally relies on another library to satisfy the MPI ordering requirements (i.e. it does not generate some sort of message sequence number) and the message lost is the last one that was sent. MPI is not allowed to attempt any matching if there is a gap in the sequence number. Rich On 2/22/08 10:22 PM, "Greg Bronevetsky" <bronevetsky1(a)llnl.gov> wrote: > > >> >I've read the Transactional Messages proposal and I am a ittle confused >> >here. Is there a reason why we believe that message faults themselves >> >should be handled by the application layer instead of the MPI library? >> >Using the latter model allows one to reduce the error conditions >> >perculated up to the user to revolve around loss of the actual >> >connection to a process (or the actual process itself). > > Actually, one aspect of the proposal is that I made sure not to > define message faults at a low level. They may be any low-level > problems that the implementation cannot efficiently deal with on its > own and that are best represented to the application as message > drops. One example of this may be process failures. Although we will > probably want to define a special notification mechanism to expose > those failures to the application, we will also need a way to expose > the failures of any communication that involves the process. Another > example may be simplified MPI implementations that do not have > facilities for resending messages because the probability of an error > is rather low and performance is too important. In fact, applications > that can tolerate message drops may explicitly choose those MPI > implementations for the performance gains. > > Greg Bronevetsky > Post-Doctoral Researcher > 1028 Building 451 > Lawrence Livermore National Lab > (925) 424-5756 > bronevetsky1(a)llnl.gov > _______________________________________________ > Mpi3-ft mailing list > Mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >

1 0

Re: [Mpi3-ft] Transactional Messages
by Greg Bronevetsky 22 Feb '08

22 Feb '08

>I've read the Transactional Messages proposal and I am a ittle confused >here. Is there a reason why we believe that message faults themselves >should be handled by the application layer instead of the MPI library? >Using the latter model allows one to reduce the error conditions >perculated up to the user to revolve around loss of the actual >connection to a process (or the actual process itself). Actually, one aspect of the proposal is that I made sure not to define message faults at a low level. They may be any low-level problems that the implementation cannot efficiently deal with on its own and that are best represented to the application as message drops. One example of this may be process failures. Although we will probably want to define a special notification mechanism to expose those failures to the application, we will also need a way to expose the failures of any communication that involves the process. Another example may be simplified MPI implementations that do not have facilities for resending messages because the probability of an error is rather low and performance is too important. In fact, applications that can tolerate message drops may explicitly choose those MPI implementations for the performance gains. Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 bronevetsky1(a)llnl.gov

1 0

Re: [Mpi3-ft] Transactional Messages
by Terry Dontje 22 Feb '08

22 Feb '08

Greg Bronevetsky wrote: > At 04:35 PM 2/19/2008, Josh Hursey wrote: > >> They are available on the Wiki at the link below: >> http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Meeting-15-Feb-2008 >> > > I've up just written up and uploaded the initial proposal for > Transactional Messages. Give it a look. BTW, I don't know how to use > this Wiki, so I've just uploaded my .txt file as a page attachment. > If there's a cleaner way to do this, someone please let me know. > > Greg Bronevetsky > Post-Doctoral Researcher > 1028 Building 451 > Lawrence Livermore National Lab > (925) 424-5756 > bronevetsky1(a)llnl.gov > _______________________________________________ > Mpi3-ft mailing list > Mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > I've read the Transactional Messages proposal and I am a ittle confused here. Is there a reason why we believe that message faults themselves should be handled by the application layer instead of the MPI library? Using the latter model allows one to reduce the error conditions perculated up to the user to revolve around loss of the actual connection to a process (or the actual process itself). --td

1 0

[Mpi3-ft] Piggybacking Proposal
by Greg Bronevetsky 21 Feb '08

21 Feb '08

I've up just uploaded the initial proposal for Point-to-Point Piggybacking to the wiki. Give it a look. Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 bronevetsky1(a)llnl.gov

1 0

[Mpi3-ft] Transactional Messages
by Greg Bronevetsky 21 Feb '08

21 Feb '08

At 04:35 PM 2/19/2008, Josh Hursey wrote: >They are available on the Wiki at the link below: > http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Meeting-15-Feb-2008 I've up just written up and uploaded the initial proposal for Transactional Messages. Give it a look. BTW, I don't know how to use this Wiki, so I've just uploaded my .txt file as a page attachment. If there's a cleaner way to do this, someone please let me know. Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 bronevetsky1(a)llnl.gov

1 0

[Mpi3-ft] test
by Richard Graham 21 Feb '08

21 Feb '08

1 0

[Mpi3-ft] Notes from 15 Feb. 2008 Meeting
by Josh Hursey 19 Feb '08

19 Feb '08

They are available on the Wiki at the link below: http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Meeting-15-Feb-2008 -- Josh

1 0

Re: [Mpi3-ft] Proposal formats
by Supalov, Alexander 15 Feb '08

15 Feb '08

Hi, I'd suggest to upload this text into Wiki and make a template out of it. Best regards. Alexander -----Original Message----- From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Richard Graham Sent: Friday, February 15, 2008 8:39 PM To: mpi3-ft(a)lists.mpi-forum.org Subject: [Mpi3-ft] Proposal formats Here is a suggestion for proposal format: ï¿½ï¿½ - An executive summary ï¿½ï¿½ - A detailed proposal which should include ï¿½ï¿½ ï¿½ ï¿½ - The problem being addressed - The approach being proposed ï¿½ï¿½ ï¿½ ï¿½ - Pro's (why this and not another approach) ï¿½ï¿½ ï¿½ ï¿½ - Con's (what are the issues that come up with this approach) - How does this impact other aspects of the standard - Semantics ï¿½ï¿½ ï¿½ ï¿½ - Can this same functionality be obtained within the current ï¿½ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ standard, but maybe in a less convenient manner - Specific API proposal ** this would be a good point for input from others, before a lot of time is spent on implementation. ** ï¿½ï¿½ ï¿½ ï¿½ - Discussion of the prototyping work - pointer to buildable source for the implementation Any suggestions on how to improve this ? Rich _______________________________________________ Mpi3-ft mailing list Mpi3-ft(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0