This will be in the next nightly 1.8.5 tarball.
Bill: can you test it to see if we’ve fixed the problem?
Thanks
Ralph
> On Apr 10, 2015, at 2:15 PM, Ralph Castain wrote:
>
> Okay, I at least now understand the behavior from this particular cmd line.
> Looks like we are binding-to-core by def
Andy - could you please try the current 1.8.5 nightly tarball and see if it
helps? The error log indicates that it is failing to get the topology from some
daemon, I’m assuming the one on the Phi?
You might also add —enable-debug to that configure line and then put -mca
plm_base_verbose on the
Okay, I at least now understand the behavior from this particular cmd line.
Looks like we are binding-to-core by default, even if you specify
use-hwthread-cpus. I’ll fix that one - still don’t understand the segfaults.
Bill: can you shed some light on those?
> On Apr 9, 2015, at 8:28 PM, Lane,
Ahh, I appreciate this explanation. This is a good thing to keep in mind. I
read up on how functions like `top` measure the processor load. Since the
OS cannot distinguish between physical and virtual cores, `top` does not
provide an accurate measurement, hence, I should not be using it as an
absol
Namu,
Hyperthreads aren't real cores, they're really just another hardware
thread (two per physical core). You have two CPUs with 6 physical cores
each. If you start 2 simulations, each with 6 MPI processes running,
your 12 physical cores will each be running at 100%. Adding another
simulat
Someone pointed out to me that it is a problem in how the mapping with
newer versions is done and that using -bind-to none resolves the issue.
On Fri, Apr 10, 2015 at 3:22 PM, namu patel wrote:
> Hello All,
>
> I am using OpenMPI 1.8.4 on my workstation with 2 CPUs, each with 12
> processors (6
Hello All,
I am using OpenMPI 1.8.4 on my workstation with 2 CPUs, each with 12
processors (6 with hyper-threading). When I run simulations using mpiexec,
I'm noticing a strange performance issue. If I run two simulations, each
with 6 processors, then everything is fine and 12 processors are under
Summary: MPI jobs work fine, SHMEM jobs work just often enough to be
tantalizing, on an Intel Xeon Phi/MIC system.
Longer version
Thanks to the excellent write-up last June
(),
I have been able to build a version of Open MPI for the Xeon Phi
coprocessor
Sorry for delay - back from travel again. The output is telling us that some of
the nodes (and I can’t tell which is which) have HT disabled (where we only
report one HT for the core), while others have it enabled (where we are bound
to both HTs of a core). I also see a mix of 4 core (containing
Had time to think about this a bit, and I believe you are absolutely correct
about the ABI - I think we accidentally broke that guarantee in the 1.8 series
with this version check. It shouldn’t have been that strict. The revised algo
is the correct one.
Sorry for the error - just completely sli
I’ve got an updated patch that adds the desired “skip version check” in the
queue - should be committed in the next hour or so. Will be in the next nightly
1.8.5 tarball
> On Apr 10, 2015, at 7:26 AM, Ralph Castain wrote:
>
> I realize there are still longer term issues, but we haven’t resolv
Sorry I didn't get back to your right away. 1) I'm on the digest, 2) not
real familiar with git and 3) just learned the hard way how to update the
build to work with the latest versions of automake, autoconf, and libtool.
:)
Anyway, I believe the patch is an improvement. Looking at it, I can tel
no need IPoIB, mxm uses native IB.
Please see HPCX (pre-compiled ompi, integrated with MXM and FCA) README
file for details how to compile/select.
The default transport is UD for internode communication and shared-memory
for intra-node.
http://bgate,mellanox.com/products/hpcx/
Also, mxm include
13 matches
Mail list logo
