Hi Pak
I can't say for certain, but I believe the problem relates to a change we
made in the summer to the default universe name. I encountered a similar
problem with the Eclipse folks at that time.
What happened was that Josh was encountering a problem relating to the
default universe name when
On Thu, Sep 07, 2006 at 07:51:28PM +0200, Adrian Knoth wrote:
> No problem, just two hours ago, Christian and me decided to drop
> the idea of oob/tcp6 and go on with only one oob-tcp-component.
> It shouldn't be that hard and I'll try it tonight or tomorrow.
Looks quite promising:
adi@ipc654:~/
On 9/7/06 1:51 PM, "Adrian Knoth" wrote:
>> (I'm willing to help with the configure.m4 mojo -- the
>
> That's good. Just check for struct sockaddr_in6 and add
> -DIPV6 to the CFLAGS. This flag is currently needed by
> opal/util/if.* and orte/mca/oob/tcp/*, so one might limit
> it to the two corr
On 9/7/06, Eng. A.A. Isola wrote:
"short-term" not scheduled? the Client-Server is the
most innovative spawning method in MPI2, and this is not very good that
OpenMPI don't have it if it wants become the "BEST" MPI2 distribuition
today available, for this moment MPICH2 and LAM are the best for
s
Hi Edgar,
I tried starting the persistent orted before running the client/server
executables without the MPI_Publish_name/MPI_Lookup_name, I am still
getting the same kind of failure, as reported by Rolf earlier (in trac#252).
The server prints the port and I feed in the port info to the clie
But sorry why in the homepage is written:
"Features implemented or in
short-term development for Open MPI include:
Full MPI-2 standards
conformance
"
"short-term" not scheduled? the Client-Server is the
most innovative spawning method in MPI2, and this is not very good that
OpenMPI don'
On 9/7/06 3:12 PM, "Eng. A.A. Isola" wrote:
>> Second, you can not use right now MPI_Publish_name/MPI_Lookup_name
>> accross multiple jobs, this is unfortunatly a known bug.
>
> Oh
> noo!!!
> This is a tremendous news1 for me!!
>
> But when you will
> resolve this problem???
We don
>Second, you can not use right now MPI_Publish_name/MPI_Lookup_name
>accross multiple jobs, this is unfortunatly a known bug.
Oh
noo!!!
This is a tremendous news1 for me!!
But when you will
resolve this problem???
Then the unique way is to use the
accept/connect routines with orte da
Hi,
sorry for the delay on your request.
There are two things which have to do in order to make a client/server
example work with Open MPI right now (assuming you are using
MPI_Comm_connect/MPI_Comm_accept)
First, you have to start the orted daemon in a persistent mode, e.g.
orted --persist
"It's not possible to connect"
Hi Devel list, crossposting as this
is getting weird...
I did a client/server using MPI_Publish_name /
MPI_Lookup_name
and it runs fine on both MPICH2 and LAM-MPI but fail
on Open MPI. It's
not a simple failure (ie. returning an error code)
it breaks the
On Thu, Sep 07, 2006 at 11:46:28AM -0400, Jeff Squyres wrote:
> > On Fri, Sep 01, 2006 at 07:01:25AM -0600, Ralph Castain wrote:
> >
> >>> Do you agree to go on with two oob components, tcp and tcp6?
> >> Yes, I think that's the right approach
> >
> > It's a deal. ;)
> Actually, I would disagree
On 9/7/06 12:42 PM, "George Bosilca" wrote:
> I still wonder why we need any configuration "magic". We don't want
> to be the only one around supporting IPv4 OR IPv6. Supporting both of
> them simultaneously can be interesting, and it does not require huge
> changes. In fact, we have a problem on
That would be great with me! And much appreciated. A design would really
help.
On 9/7/06 10:42 AM, "George Bosilca" wrote:
> I still wonder why we need any configuration "magic". We don't want
> to be the only one around supporting IPv4 OR IPv6. Supporting both of
> them simultaneously can be i
Hi Devel list, crossposting as this is getting weird...
Alfonso did a client/server using MPI_Publish_name / MPI_Lookup_name
and it runs fine on both MPICH2 and LAM-MPI but fail on Open MPI. It's
not a simple failure (ie. returning an error code) it breaks the
execution line and quits. The server
I still wonder why we need any configuration "magic". We don't want
to be the only one around supporting IPv4 OR IPv6. Supporting both of
them simultaneously can be interesting, and it does not require huge
changes. In fact, we have a problem only at the connection step,
everything else wil
Jeff and I talked about this for awhile this morning, and we both agree
(yes, I did change my mind after we discussed all the ramifications). It
appears that we should be able to consolidate the code into a single
component with the right configuration system "magic" - and that would
definitely be
On 9/1/06 12:21 PM, "Adrian Knoth" wrote:
> On Fri, Sep 01, 2006 at 07:01:25AM -0600, Ralph Castain wrote:
>
>>> Do you agree to go on with two oob components, tcp and tcp6?
>> Yes, I think that's the right approach
>
> It's a deal. ;)
Actually, I would disagree here (sorry for jumping in late
17 matches
Mail list logo
