This is a resend since it looks like some people didn't get the agenda
for some reason.
--td
--- Begin Message ---
Please let me know if you have any other agenda topics for this week's telecon.
List-Post: devel@lists.open-mpi.org
Date: December 4, 2007
Time: 11am Eastern/New York
Dial-in numbe
Yo all
As (I hope) many of you know, we are in a final phase of revamping ORTE to
simplify the code, enhance scalability, and improve reliability. In working
on this effort, we recently uncovered four issues that merit broader
discussion (apologies in advance for verbosity). Although these somewha
I. Support for non-MPI jobs
Considerable complexity currently exists in ORTE because of the stipulation
in our first requirements document that users be able to mpirun non-MPI jobs
- i.e., that we support such calls as "mpirun -n 100 hostname". This creates
a situation, however, where the RTE canno
II. Interaction between the ROUTED and GRPCOMM frameworks
When we initially developed these two frameworks within the RTE, we
envisioned them to operate totally independently of each other. Thus, the
grpcomm collectives provide algorithms such as a binomial "xcast" that uses
the daemons to scalably
III. Collective communications across daemons
A few months ago, we deliberately extended the abstraction between the RTE
and MPI layers to reduce their interaction. This has generally been
perceived as a good thing, but it did have a cost: namely, it increased the
communications required during lau
Dear all,
As I see some activity on a related ticked, below some comments I
sended to Bill Gropp some days ago about this subject. Bill did not
write me back, I know he is really busy.
Group operations are supposed to return new groups, so the used has to
free the result. Additionally, the standa
IV. RTE/MPI relative modex responsibilities
The modex operation conducted during MPI_Init currently involves the
exchange of two critical pieces of information:
1. the location (i.e., node) of each process in my job so I can determine
who shares a node with me. This is subsequently used by the sha
On Dec 4, 2007, at 10:43 AM, Lisandro Dalcin wrote:
* MPI_GROUP_EMPTY cannot be freed, as it is a predefined handle. Users
have to always check if the result of a group operation is
MPI_GROUP_EMPTY to know if they can or cannot free them. This way is
similar to the current management of predefin
On Dec 4, 2007, at 10:11 AM, Ralph H Castain wrote:
(a) do we want to retain the feature to run non-MPI jobs with mpirun
as-is
(and accept the tradeoffs, including the one described below in II)?
(b) do we provide a flag to mpirun (perhaps adding the distinction
that
"orterun" must be used
Jon Mason wrote:
While working on OMPI udapl btl, I have noticed some "interesting"
behavior. OFA udapl wants the evd queues to be a power of 2 and
then will subtract 1 for book keeping (ie, so that internal head and
tail pointers never touch except when the ring is empty). OFA udapl
will repor
On Tue, Dec 04, 2007 at 11:40:17AM -0800, Arlin Davis wrote:
> Jon Mason wrote:
>> While working on OMPI udapl btl, I have noticed some "interesting"
>> behavior. OFA udapl wants the evd queues to be a power of 2 and
>> then will subtract 1 for book keeping (ie, so that internal head and
>> tail p
11 matches
Mail list logo
