If I understand correctly your question, then we don't need any
extension. Each request has a unique ID (from PERUSE perspective).
However, if I remember well this is only half implemented in our
PERUSE layer (i.e. it works only for expected requests). This should
be quite easy to fix, if s
Thanks for the clarification everyone.
Tim
On Monday 05 November 2007 05:41:00 pm Torsten Hoefler wrote:
> On Mon, Nov 05, 2007 at 05:32:04PM -0500, Brian W. Barrett wrote:
> > On Mon, 5 Nov 2007, Torsten Hoefler wrote:
> > > On Mon, Nov 05, 2007 at 04:57:19PM -0500, Brian W. Barrett wrote:
> > >
On Mon, Nov 05, 2007 at 05:32:04PM -0500, Brian W. Barrett wrote:
> On Mon, 5 Nov 2007, Torsten Hoefler wrote:
>
> > On Mon, Nov 05, 2007 at 04:57:19PM -0500, Brian W. Barrett wrote:
> >> This is extremely tricky to do. How do you know which environment
> >> variables to forward (foo in this case
> This is extremely tricky to do. How do you know which environment
> variables to forward (foo in this case) and which not to (hostname).
> SLURM has a better chance, since it's linux only and generally only run on
> tightly controlled clusters. But there's a whole variety of things that
> s
On Mon, 5 Nov 2007, Torsten Hoefler wrote:
On Mon, Nov 05, 2007 at 04:57:19PM -0500, Brian W. Barrett wrote:
This is extremely tricky to do. How do you know which environment
variables to forward (foo in this case) and which not to (hostname).
SLURM has a better chance, since it's linux only a
On Mon, Nov 05, 2007 at 04:57:19PM -0500, Brian W. Barrett wrote:
> This is extremely tricky to do. How do you know which environment
> variables to forward (foo in this case) and which not to (hostname).
> SLURM has a better chance, since it's linux only and generally only run on
> tightly con
This is extremely tricky to do. How do you know which environment
variables to forward (foo in this case) and which not to (hostname).
SLURM has a better chance, since it's linux only and generally only run on
tightly controlled clusters. But there's a whole variety of things that
shouldn't b
Hi,
After talking with Torsten today I found something weird. When using the SLURM
pls we seem to forward a user's environment, but when using the rsh pls we do
not.
I.e.:
[tprins@odin ~]$ mpirun -np 1 printenv |grep foo
[tprins@odin ~]$ export foo=bar
[tprins@odin ~]$ mpirun -np 1 printenv |gr
On Nov 5, 2007, at 2:02 PM, Tim Prins wrote:
This commit causes a bunch of warnings of the type:
runtime/opal_init.c:55:2: warning: #ident is a GCC extension
runtime/orte_init.c:92:2: warning: #ident is a GCC extension
pinit.c:32:2: warning: #ident is a GCC extension
pinit_f.c:26:2: warning: #i
Hi,
Commit 16364 broke things when using multiword mca param values. For
instance:
mpirun --debug-daemons -mca orte_debug 1 -mca pls rsh -mca pls_rsh_agent
"ssh -Y" xterm
Will crash and burn, because the value "ssh -Y" is being stored into the
argv orted_cmd_line in orterun.c:1506. This is
Hi,
This commit causes a bunch of warnings of the type:
runtime/opal_init.c:55:2: warning: #ident is a GCC extension
runtime/orte_init.c:92:2: warning: #ident is a GCC extension
pinit.c:32:2: warning: #ident is a GCC extension
pinit_f.c:26:2: warning: #ident is a GCC extension
Thanks,
Tim
e
Currently in order to do message tracing one either has to rely on some
error prone postprocessing of data or replicating some MPI internals up
in the PMPI layer. It would help Sun's tools group (and I believe U
Dresden also) if Open MPI would create a couple APIs that exoposed the
following:
12 matches
Mail list logo
