Hi All,
I am new to MPI library. I downloaded and started using OpenMPI library to
build MPI programs. I wanted to know how does MPI program communicates over
the network. I am trying to trace the flow of MPI_Send and MPI_Bcast APIS to
find the actual send/recv calls being used for sending the pac
Well, if reviving means making device failover work, then yes, in a way we
revived it ;)
We are currently making mostly experiments to figure out how to have device
failover working. No big fixes for now, and that's why we are posting here
before going further.
From what I understand, Rolf's
Hi All,
I am new to MPI library. I downloaded and started using OpenMPI library to
build MPI programs. I wanted to know how does MPI program communicates over
the network. I am trying to trace the flow of MPI_Send and MPI_Bcast APIS to
find the actual send/recv calls being used for sending the pac
Sounds fine, though note that we don't want ob1 itself to do this as
it inevitably adds overhead that translates into latency. Instead, we
want that functionality to be in a separate component for those people
who want to use it.
We did talk on a telecon earlier this week about the need to
On Apr 16, 2009, at 9:12 AM, Ralph Castain wrote:
Sounds fine, though note that we don't want ob1 itself to do this as
it inevitably adds overhead that translates into latency. Instead, we
want that functionality to be in a separate component for those people
who want to use it.
To drive this
Cisco's MTT testing had some more false failures last night, but I
think the attribute issues were the last real errors. I'd be ok with
making an rc today if all other issues are good.
(I'd like to get some more MTT in with the rc, but I *think* I've
rooted out all the false MTT failures..
>From what I understand MPI_Send will hit 3 separate layers of code before
reaching the socket file descriptors you've found. The PML (Point to Point
Messaging Layer) is a layer that bridges the MPI semantics from the
underlying point to point communications. The standard PML implementation is
call
What would the MIPS/Linux port miss if ompi_info prints:
Thread support: posix (mpi: yes, progress: yes)
TIA,
Rayson
On Tue, Apr 14, 2009 at 10:00 AM, Rayson Ho wrote:
> I googled but found no precise answer...
>
> Is it true that some features are disabled if the code is not
> supported for
Working on it now...
On Apr 16, 2009, at 9:20 AM, Jeff Squyres wrote:
Cisco's MTT testing had some more false failures last night, but I
think the attribute issues were the last real errors. I'd be ok
with making an rc today if all other issues are good.
(I'd like to get some more MTT in
Hi,
I think I have a better fix for this issue. It is to simply #include
*before* ompi_config.h.
--- ompi/mca/common/mx/common_mx.c
+++ ompi/mca/common/mx/common_mx.c
@@ -19,15 +19,16 @@
* $HEADER$
*/
+#ifdef HAVE_MALLOC_H
+#include
+#endif
+
#include "ompi_config.h"
I don't think this is correct. We are not supposed to include anything
before the ompi_config.h. Moreover, in the case we redefine what
malloc is, this will be the only piece of code that will use the real
malloc.
I wonder why we need to include malloc.h there? We don't allocate any
memor
Hello Tim,
Thanks for providing the details. I was going through the code of MPI_Send
and I found a function pointer being invoked mca_pml.send of struct
mca_pml_base_module_t. I am trying to figureout when are these PML function
pointers get initialized to call internal BTL functions. I am trying
12 matches
Mail list logo
