Apparently, I can't read -- I'm sorry; you did say exactly the right thing and
my eyes parsed it wrong.
Yes, you did the right thing by removing mca_btl_mx.*.
I can't imagine why you're getting those errors -- there should be nothing else
in OMPI that refers to mca_btl_mx.*.
*** George -- an
I'm confused now :).
I thought that's what I did, removing "mca_btl_mx.la" and
"mca_btl_mx.so". This is the MX BTL plugin, right?
On Fri, Jun 29, 2012 at 11:16 AM, Jeff Squyres wrote:
> On Jun 29, 2012, at 2:14 PM, Yong Qin wrote:
>
>> Thanks Jeff for the doc. However I'm not sure if I understan
On Jun 29, 2012, at 2:14 PM, Yong Qin wrote:
> Thanks Jeff for the doc. However I'm not sure if I understand your
> following comment correctly. If I remove the MX BTL plugins, a.k.a.,
> mca_btl_mx.la and mca_btl_mx.so, I'm now getting errors of these
> components not found.
>
> [n0026.hbar:09467
Thanks Jeff for the doc. However I'm not sure if I understand your
following comment correctly. If I remove the MX BTL plugins, a.k.a.,
mca_btl_mx.la and mca_btl_mx.so, I'm now getting errors of these
components not found.
[n0026.hbar:09467] mca: base: component_find: unable to open
.../mca_btl_mx
On Jun 28, 2012, at 8:04 PM, Yong Qin wrote:
> Thanks to Jeff, we now have a bug registered with the segv issue.
There may be some confusion here with the fact that OMPI supports 2 different
MX transports: an MTL and a BTL. Here's what the README says:
-
- Myrinet MX (and Open-MX) support
Thanks to Jeff, we now have a bug registered with the segv issue.
Now we are moving to the testing with a myrinet onboard, but we are
also having some unexpected issues.
1. If we don't specify which BTL to use, my understanding is that it
should pick up the mx btl if openib is not available. Howe
On Jun 11, 2012, at 7:48 PM, Yong Qin wrote:
> ah, I guess my original understanding of PML was wrong. Adding "-mca
> pml ob1" does help to ease the problem.
See the README for a little more discussion about this issue. There can only
be 1 PML in use by a given MPI job -- using "--mca pml ob1"
ah, I guess my original understanding of PML was wrong. Adding "-mca
pml ob1" does help to ease the problem. But the question still
remains. Why ompi decided to use the mx BTL in the first place, given
there's no physical device onboard at all? This behavior is completely
different than the origina
Hi Aurelien,
Thanks for the explanation. But I'm not following it. There's no MX
device on the test machine as I mentioned, so ompi should not find it
at all in the first place. I'm also not able to locate the ob1 MTL.
There's the ob1 PML but I don't understand how that's going to affect
the mx BT
Le 11 juin 2012 à 18:57, Aurélien Bouteiller a écrit :
> Hi,
>
> If some mx devices are found, the logic is not only to use the mx BTL but
> also to use the mx MTL. You can try to disable this with --mca mtl ob1.
>
Sorry, I meant --mca pml ob1
> Aurelien
>
>
>
>
> Le 11 juin 2012 à 18:24
Hi,
If some mx devices are found, the logic is not only to use the mx BTL but also
to use the mx MTL. You can try to disable this with --mca mtl ob1.
Aurelien
Le 11 juin 2012 à 18:24, Yong Qin a écrit :
> Hi,
>
> We are migrating to Open MPI 1.6 but since 1.6 dropped support for
> Myricom
Hi,
We are migrating to Open MPI 1.6 but since 1.6 dropped support for
Myricom GM driver so we have to switch to the MX driver. We have the
Myricom MX2G 1.2.16 driver installed. However upon testing the new
build of Open MPI on a node without the actual Myrinet device, we are
getting the following
12 matches
Mail list logo
