Hi Laurence,
I don't know whether it's as bad as a deadly sin, but for us parallel writes
are a huge problem and we get complete garbage in the file. Take a look at:
Implementing MPI-IO Atomic Mode and Shared File Pointers Using MPI One-Sided
Communication, * Robert Latham,*Robert Ross*, *Rajeev
Thanks, that explains it :)
On Tue, Jan 19, 2010 at 15:01, Ralph Castain wrote:
> Shared memory doesn't extend between comm_spawn'd parent/child processes in
> Open MPI. Perhaps someday it will, but not yet.
>
>
> On Jan 19, 2010, at 1:14 PM, Nicolas Bock wrote:
>
c ticket 2043, which describes problems with the sm BTL
> exposed by GCC 4.4.x compilers. You need to get a sufficiently recent build
> to solve this. But, those problems don't occur until you start passing
> messages, and here you're not even starting up.
>
>
> Nicol
Sorry, I forgot to give more details on what versions I am using:
OpenMPI 1.4
Ubuntu 9.10, kernel 2.6.31-16-generic #53-Ubuntu
gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1
On Fri, Jan 15, 2010 at 15:47, Nicolas Bock wrote:
> Hello list,
>
> I am running a job on a 4 quadcore AMD Opteron. Thi
Hello list,
I am running a job on a 4 quadcore AMD Opteron. This machine has 16 cores,
which I can verify by looking at /proc/cpuinfo. However, when I run a job
with
mpirun -np 16 -mca btl self,sm job
I get this error:
--
A
Hi Ralph,
I have confirmed that openmpi-1.4a1r22335 works with my master, slave
example. The temporary directories are cleaned up properly.
Thanks for the help!
nick
On Thu, Dec 17, 2009 at 13:38, Nicolas Bock wrote:
> Ok, I'll give it a try.
>
> Thanks, nick
>
>
>
&g
Ok, I'll give it a try.
Thanks, nick
On Thu, Dec 17, 2009 at 12:44, Ralph Castain wrote:
> In case you missed it, this patch should be in the 1.4 nightly tarballs -
> feel free to test and let me know what you find.
>
> Thanks
> Ralph
>
> On Dec 2, 2009, at 10
his list so
that maybe in the future someone will work on implementing MPI_Barrier()
differently.
nick
On Fri, Dec 4, 2009 at 17:37, Jeff Squyres wrote:
> On Dec 4, 2009, at 6:54 PM, Nicolas Bock wrote:
>
> > in our code we use a very short front-end program to drive a larger set
>
Hello list,
in our code we use a very short front-end program to drive a larger set of
codes that do our calculations. Right in the beginning of the front-end, we
have an if() statement such that only the rank 0 front-end does something,
and the other ranks go right away to an MPI_Barrier() statem
On Fri, Dec 4, 2009 at 12:10, Eugene Loh wrote:
> Nicolas Bock wrote:
>
> On Fri, Dec 4, 2009 at 10:29, Eugene Loh wrote:
>
>> I think you might observe a world of difference if the master issued some
>> non-blocking call and then intermixed MPI_Test calls with sleep c
On Fri, Dec 4, 2009 at 10:29, Eugene Loh wrote:
> Nicolas Bock wrote:
>
> On Fri, Dec 4, 2009 at 10:10, Eugene Loh wrote:
>
>> Yield helped, but not as effectively as one might have imagined.
>>
>
> Yes, that's the impression I get as well, the master
On Fri, Dec 4, 2009 at 10:10, Eugene Loh wrote:
> Nicolas Bock wrote:
>
> On Fri, Dec 4, 2009 at 08:21, Ralph Castain wrote:
>
>> You used it correctly. Remember, all that cpu number is telling you is the
>> percentage of use by that process. So bottom line is: we are
On Fri, Dec 4, 2009 at 08:21, Ralph Castain wrote:
> You used it correctly. Remember, all that cpu number is telling you is the
> percentage of use by that process. So bottom line is: we are releasing it as
> much as we possibly can, but no other process wants to use the cpu, so we go
> ahead and
On Fri, Dec 4, 2009 at 08:03, Ralph Castain wrote:
>
>
> It is polling at the barrier. This is done aggressively by default for
> performance. You can tell it to be less aggressive if you want via the
> yield_when_idle mca param.
>
>
How do I use this parameter correctly? I tried
/usr/local/open
Hello list,
when I run the attached example, which spawns a "slave" process with
MPI_Comm_spawn(), I see the following:
nbock19911 0.0 0.0 53980 2288 pts/0S+ 07:42 0:00
/usr/local/openmpi-1.3.4-gcc-4.4.2/bin/mpirun -np 3 ./master
nbock19912 92.1 0.0 158964 3868 pts/0R+
That was quick. I will try the patch as soon as you release it.
nick
On Wed, Dec 2, 2009 at 21:06, Ralph Castain wrote:
> Patch is built and under review...
>
> Thanks again
> Ralph
>
> On Dec 2, 2009, at 5:37 PM, Nicolas Bock wrote:
>
> Thanks
>
> On Wed, Dec 2
mpi/changeset/21498
> >
> > There was an issue about orte_session_dir_finalize() not
> > cleaning up the session directories properly.
> >
> > Hope that helps.
> >
> > Abhishek
> >
> >> Thanks again
> >> Ralph
> >> On Dec 2, 2009, at 2:4
On Wed, Dec 2, 2009 at 14:23, Ralph Castain wrote:
> Hmmif you are willing to keep trying, could you perhaps let it run for
> a brief time, ctrl-z it, and then do an ls on a directory from a process
> that has already terminated? The pids will be in order, so just look for an
> early number (
On Wed, Dec 2, 2009 at 12:12, Ralph Castain wrote:
>
> On Dec 2, 2009, at 10:24 AM, Nicolas Bock wrote:
>
>
>
> On Tue, Dec 1, 2009 at 20:58, Nicolas Bock wrote:
>
>>
>>
>> On Tue, Dec 1, 2009 at 18:03, Ralph Castain wrote:
>>
>>> You
On Tue, Dec 1, 2009 at 20:58, Nicolas Bock wrote:
>
>
> On Tue, Dec 1, 2009 at 18:03, Ralph Castain wrote:
>
>> You may want to check your limits as defined by the shell/system. I can
>> also run this for as long as I'm willing to let it run, so something e
or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_session_dir failed
--> Returned value Error (-1) instead of ORTE_SUCCESS
> On Dec 1, 2009, at 4:38 PM, Nicolas
On Tue, Dec 1, 2009 at 16:28, Abhishek Kulkarni wrote:
> On Tue, Dec 1, 2009 at 6:15 PM, Nicolas Bock
> wrote:
> > After reading Anthony's question again, I am not sure now that we are
> having
> > the same problem, but we might. In any case, the attached example
n what kind of platform.
>
> This issue was fixed to the best of my knowledge (not all the pipes were
> getting closed), but I would have to look and see what release might contain
> the fix...would be nice to know where to start.
>
>
> On Dec 1, 2009, at 4:15 PM, Nicolas Bo
ll the pipes were
> getting closed), but I would have to look and see what release might contain
> the fix...would be nice to know where to start.
>
>
> On Dec 1, 2009, at 4:15 PM, Nicolas Bock wrote:
>
> After reading Anthony's question again, I am not sure now that we are
&
Dec 1, 2009 at 16:08, Nicolas Bock wrote:
> Hello list,
>
> a while back in January of this year, a user (Anthony Thevenin) had the
> problem of running out of open pipes when he tried to use MPI_Comm_spawn a
> few times. As I the thread his started in the mailing list archives and
Hello list,
a while back in January of this year, a user (Anthony Thevenin) had the
problem of running out of open pipes when he tried to use MPI_Comm_spawn a
few times. As I the thread his started in the mailing list archives and have
just joined the mailing list myself, I unfortunately can't rep
26 matches
Mail list logo
