More positive results, with a caveat.
On this cluster, statfs() is returning ENOENT, which is breaking
opal_path_nfs().
So, these results are with test/opal/util/opal_path_nfs.c "disabled".
PASS (defined as "make all install check")
Linux/ppc32 with xlc-11.1 and xlf-13.1 compilers
Linux/
On Jan 27, 2012, at 12:45 AM, Paul H. Hargrove wrote:
> On this cluster, statfs() is returning ENOENT, which is breaking
> opal_path_nfs().
> So, these results are with test/opal/util/opal_path_nfs.c "disabled".
Paul -- can you explain this a little more? There should be logic in there to
effe
On Jan 26, 2012, at 8:54 PM, Paul Hargrove wrote:
> libtool: link: pgcc -O -DNDEBUG -o orte-clean orte-clean.o
> ../../../orte/.libs/libopen-rte.a
> /Users/paul/openmpi-1.4.5rc2/BLD-pgi-11.10/opal/.libs/libopen-pal.a -lutil
> Undefined symbols for architecture x86_64:
> "_orte_odls", referenc
Hello @ll.
George, i'm using some pieces of the pessimist vprotocol. I've observed
that when you do a send, you call vprotocol_receiver_event_flush and here
the macro *__VPROTOCOL_RECEIVER_SEND_BUFFER* is called. I've noticed that
here you try send a copy of the message to process 0 using the el_c
Hugo,
Your program does not have non-deterministic events. Therefore, there are no
events to log. If you add MPI_ANY_SOURCE, you should see this code being
called. Please contact me again if you need more help.
Aurelien
Le 27 janv. 2012 à 10:21, Hugo Daniel Meyer a écrit :
> Hello @ll.
>
>
Hello Aurélien.
Thanks for the clarification. Considering what you've mentioned i will have
to make some adaptations, because to me, every single message has to be
logged. So, a sender not only will be sending messages to the receiver, but
also to an event logger. Is there any considerations that
Hugo,
It seems you want to implement some sort of remote pessimistic logging -a la
MPICH-V1- ?
MPICH-V: Toward a Scalable Fault Tolerant MPI for Volatile Nodes -- George
Bosilca, Aurélien Bouteiller, Franck Cappello, Samir Djilali, Gilles Fédak,
Cécile Germain, Thomas Hérault, Pierre Lemarini
Hi,
If a job is launched using "srun --resv-ports --cpu_bind:..." and slurm
is configured with:
TaskPlugin=task/affinity
TaskPluginParam=Cpusets
each rank of that job is in a cpuset that contains a single CPU.
Now, if we use carto on top of this, the following happens in
get_ib_dev_distanc
On Fri, Jan 27, 2012 at 5:34 AM, Jeff Squyres wrote:
[snip]
>
>
> I'm not quite sure how that can happen -- orte_odls appears to be
> prototyped properly in orte/mca/odls/odls.h (i.e., it has ORTE_DECLSPEC,
> for visibility), and is properly instantiated in
> orte/mca/odls/base/odls_base_open.c.
>
On 1/27/2012 5:24 AM, Jeff Squyres wrote:
On Jan 27, 2012, at 12:45 AM, Paul H. Hargrove wrote:
On this cluster, statfs() is returning ENOENT, which is breaking
opal_path_nfs().
So, these results are with test/opal/util/opal_path_nfs.c "disabled".
Paul -- can you explain this a little more?
No bad news this time.
I grabbed the latest free versions of Open64 and PathScale and gave them
a try:
PASS:
linux/x86-64 w/ Open64-4.5.1 compilers from AMD
linux/x86-64 w/ ekopath-4.0.12.1 compilers from PathScale
Where "PASS" is my usual "make all install check".
-Paul
On 1/19/2012 9:
11 matches
Mail list logo
