Next week;
-----Original Message-----
From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Greg Bronevetsky
Sent: Wednesday, March 04, 2009 9:13 AM
To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group
Subject: [Mpi3-ft] telecon
Are we having a call today?
Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1(a)llnl.gov
http://greg.bronevetsky.com
_______________________________________________
mpi3-ft mailing list
mpi3-ft(a)lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
George & me we are waiting, listening to the nice ring tone
Thomas
Le 4 mars 09 � 12:13, Greg Bronevetsky a �crit :
> Are we having a call today?
>
> Greg Bronevetsky
> Post-Doctoral Researcher
> 1028 Building 451
> Lawrence Livermore National Lab
> (925) 424-5756
> bronevetsky1(a)llnl.gov
> http://greg.bronevetsky.com
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>
Are we having a call today?
Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1(a)llnl.gov
http://greg.bronevetsky.com
Thanks. I think we're looking for a better solution for both implementors and users. If this includes keeping things simple, so be it. If the low-level interface can prove its worth in advanced scenarios, the better.
________________________________
From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Greg Bronevetsky
Sent: Tuesday, March 03, 2009 7:52 PM
To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group; MPI 3.0 Fault Tolerance and Dynamic Process Control working Group
Subject: Re: [Mpi3-ft] MPI Fault Tolerance scenarios
Right. The low-level interface may be optional.
That would be an interesting choice for the API: provide several levels of support and for each level provide an optional lower-level API that can be used to control recovery more finely than would be possible using the default error handlers. I think that we'll need an explicit communicator rejoin API even when using built-in error handlers but at least we won't force users to manually check error codes. Having this double stack leaves me worried that the low-level API will simply get dropped because the rest of the forum will not see the need for something that complicated. However, I think we'll have a few very persuasive arguments such as the fact that checking for failures immediately after every collective will have a huge performance hit, whereas giving control to the user will make it efficient.
Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1(a)llnl.gov
http://greg.bronevetsky.com<http://greg.bronevetsky.com/>
---------------------------------------------------------------------
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.
>Right. The low-level interface may be optional.
That would be an interesting choice for the API: provide several
levels of support and for each level provide an optional lower-level
API that can be used to control recovery more finely than would be
possible using the default error handlers. I think that we'll need an
explicit communicator rejoin API even when using built-in error
handlers but at least we won't force users to manually check error
codes. Having this double stack leaves me worried that the low-level
API will simply get dropped because the rest of the forum will not
see the need for something that complicated. However, I think we'll
have a few very persuasive arguments such as the fact that checking
for failures immediately after every collective will have a huge
performance hit, whereas giving control to the user will make it efficient.
Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1(a)llnl.gov
http://greg.bronevetsky.com
Right. The low-level interface may be optional.
________________________________
From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Greg Bronevetsky
Sent: Monday, March 02, 2009 7:41 PM
To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group; MPI 3.0 Fault Tolerance and Dynamic Process Control working Group
Subject: Re: [Mpi3-ft] MPI Fault Tolerance scenarios
What I'm proposing is:
- Define a standard set of FT error handlers for a defined set of policies (see, e.g., Bronis' proposal aired at the telecon: nothing, local MPI calls, pt2pt w/o affected process, coll w/o affected process, pt2pt w/ affected process, coll w/ affected process)
- Provide a prototype implementation of those handlers in terms of the proposed API
- Allow implementors to provide error handlers that do not use this API, if they find a better way of fixing particular FT issues up
- Allow users to create their own error handlers using the proposed API, to which end the API should be functional inside an error handler
Alexander, just to clarify, are you suggesting that we have two APIs, one low-level API and another API that consists of easy-to-use error handlers?
Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1(a)llnl.gov
http://greg.bronevetsky.com<http://greg.bronevetsky.com/>
---------------------------------------------------------------------
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.
>What I'm proposing is:
>
>- Define a standard set of FT error handlers for a defined set of
>policies (see, e.g., Bronis' proposal aired at the telecon: nothing,
>local MPI calls, pt2pt w/o affected process, coll w/o affected
>process, pt2pt w/ affected process, coll w/ affected process)
>- Provide a prototype implementation of those handlers in terms of
>the proposed API
>- Allow implementors to provide error handlers that do not use this
>API, if they find a better way of fixing particular FT issues up
>- Allow users to create their own error handlers using the proposed
>API, to which end the API should be functional inside an error handler
Alexander, just to clarify, are you suggesting that we have two APIs,
one low-level API and another API that consists of easy-to-use error handlers?
Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1(a)llnl.gov
http://greg.bronevetsky.com
