On Wed, Jun 13, 2007 at 10:01:20PM -0400, Patrick Geoffray wrote:
> Jeff Squyres wrote:
> > Let's take a step back and see exactly what we *want*. Then we can
> > talk about how to have an interface for it.
>
> I must be missing something but why is the bandwidth/latency passed by
> the user
Jeff Squyres wrote:
Let's take a step back and see exactly what we *want*. Then we can
talk about how to have an interface for it.
I must be missing something but why is the bandwidth/latency passed by
the user (by whatever means) ? Would it be easier to automagically get
these values by
On Jun 13, 2007, at 9:43 PM, Jeff Squyres wrote:
More specifically, I'm proposing two things:
1. The MCA system itself accept this ini-style file that keys off
hostnames so that this works across all of Open MPI.
2. The bandwidth/latency MCA params accept values in two forms:
- a single
On Jun 13, 2007, at 1:48 PM, Gleb Natapov wrote:
3. Use a file to convey this information, because it's better suited
to what we're trying to do (vs. MCA parameters).
Seriously, why is a file a bad thing? The file can list interfaces
by hostname. For example, if you have a heterogeneous
On Wed, 13 Jun 2007, Jeff Squyres wrote:
I don't mind having some MCA parameters that are never showed by
ompi_info
(we already have the hidden ones). Anyway, for TCP by default there
is the
btl_tcp_latency and btl_tcp_bandwidth which will be used as a default
value for all NICs. For the
On Jun 13, 2007, at 11:32 AM, George Bosilca wrote:
Right ... blame me :) The problem is that we have to know the
number of
interfaces in order to be able to generate the MCA parameters, and the
number of interfaces will only be know inside the init call (and I
really
doon't think it's a
On Wed, 13 Jun 2007, Gleb Natapov wrote:
I'm not particularly fond of creating variable MCA parameters after
the btl open call because they won't show up in ompi_info. Should we
do something else if you want to override bandwidths, perhaps
something similar to the HCA params file? If you
On Wed, Jun 13, 2007 at 11:03:09AM -0400, Jeff Squyres wrote:
> Hey Gleb --
>
> Can you explain the rationale for this change? Is there a reason why
> the bandwidths reported by the IBV API are not sufficient? Are you
> trying to do creative things with multi-LID scenarios (perhaps QOS-
>
Hey Gleb --
Can you explain the rationale for this change? Is there a reason why
the bandwidths reported by the IBV API are not sufficient? Are you
trying to do creative things with multi-LID scenarios (perhaps QOS-
like things)? If so, this looks like a good idea, but I'm not sure
