Yo folks
For those not following the user list, this request was generated today:
Absolutely, these are useful time and time again so should be part of
the API and hence stable. Care to mention what they are and I'll add it
to my note as something to change when upgrading to 1.3 (
Has anyone else seen the trunk incur approximately a 10% increase in
latency? I think this has happened in the last couple weeks. I have
verified that it isn't due to the recheck put into the
sm_component_progress. I am about ready to try and track this down but
wanted to throw this out ther
Ummm...I actually was talking about the "PLM", not the "PML".
But I believe what you suggest concurs with what I said. In the PLM, you
could still provide multiple components you want considered, though it has
less meaning there. My suggestion really is only that we eliminate the
params to adjust
We don't want the user to have to select by hand the best PML. The
logic inside the current selection process selects the best pml for
the underlying network. However changing the priority is pretty
meaningless from the user's point of view. So while retaining the
selection process includin
Okay, another fun one. Some of the PLM modules use MCA params to adjust
their relative selection priority. This can lead to very unexpected behavior
as which module gets selected will depend on the priorities of the other
selectable modules - which changes from release to release as people
independ
I suppose we could even just make it an mpirun cmd line param, at that
point. As an MCA param, though, we have typically insisted on a particular
syntax that includes framework and component...
On 7/11/08 8:41 AM, "Don Kerr" wrote:
> For something as fundamental as launch do we still need to sp
For something as fundamental as launch do we still need to specify the
component, could it just be "launch_agent"?
Jeff Squyres wrote:
Sounds good to me. We've done similar things in other frameworks --
put in MCA base params for things that all components could use. How
about plm_base_launc
Sounds good to me. We've done similar things in other frameworks --
put in MCA base params for things that all components could use. How
about plm_base_launch_agent?
On Jul 11, 2008, at 10:17 AM, Ralph H Castain wrote:
Since the question of backward compatibility of params came up... ;-)
Ralph H Castain wrote:
On 7/11/08 7:48 AM, "Terry Dontje" wrote:
Jeff Squyres wrote:
Check that -- Ralph and I talked more about #1383 and have come up
with a decent/better solution that a) is not wonky and b) does not
involve MCA parameter synonyms. We're working on it in an hg and
On Jul 11, 2008, at 9:48 AM, Terry Dontje wrote:
Check that -- Ralph and I talked more about #1383 and have come up
with a decent/better solution that a) is not wonky and b) does not
involve MCA parameter synonyms. We're working on it in an hg and
will put it back when done (probably withi
Since the question of backward compatibility of params came up... ;-)
I've been perusing the various PLM modules to check consistency. One thing I
noted right away is that -every- PLM module registers an MCA param to let
the user specify an orted cmd. I believe this specifically was done so
people
On 7/11/08 7:48 AM, "Terry Dontje" wrote:
> Jeff Squyres wrote:
>> Check that -- Ralph and I talked more about #1383 and have come up
>> with a decent/better solution that a) is not wonky and b) does not
>> involve MCA parameter synonyms. We're working on it in an hg and will
>> put it back w
Jeff Squyres wrote:
Check that -- Ralph and I talked more about #1383 and have come up
with a decent/better solution that a) is not wonky and b) does not
involve MCA parameter synonyms. We're working on it in an hg and will
put it back when done (probably within a business day or three).
So
I can find no reason that this failed. :-\
I am unable to duplicate the problem, and this area of code has not
changed in a while -- I don't know why plpa/src/plpa-taskset/parser.c
would suddenly be left behind.
On Jul 10, 2008, at 9:24 PM, MPI Team wrote:
ERROR: Command returned a no
On Thu, 10 Jul 2008, Pavel Shamis (Pasha) wrote:
FYI the issue was resolved - https://svn.open-mpi.org/trac/ompi/ticket/1376
Indeed, no more IBCM error message displayed with r18878. Thank you !
--
Bogdan Costescu
IWR, University of Heidelberg, INF 368, D-69120 Heidelberg, Germany
Phone: +49
On Thu, 10 Jul 2008, Ralph Castain wrote:
We would appreciate it if people could test this to the extent
possible over the next few days. Please let us know (good or bad) so
we can decide whether or not to move it to the 1.3 release branch.
I've tested with r18878 and the strange behaviour me
16 matches
Mail list logo
