I am out of the office until 03/31/2011.
I will be out of the office from now on - I will not see email or check
phone messages.
Good luck to you all
Contact my former team leader: Charles J. Archer
E-mail: arch...@us.ibm.com
Phone: 553-0346 / 1-507-253-0346
OR
My former manager: Carl F.
It seems to me the MPI_Get_processor_name description is too ambiguous to
make this 100% portable. I assume most MPI implementations simply use the
hostname so all processes on the same host will return the same string.
The suggestion would work then.
However, it would also be reasonable for
Also -
HPC clusters are commonly dedicated to running parallel jobs with exactly
one process per CPU. HPC is about getting computation done and letting a
CPU time slice among competing processes always has overhead (CPU time not
spent on the computation).
Unless you are trying to run extra
I am out of the office until 11/01/2010.
I will be out of the office on vacation the last week of Oct. Back Nov 1.
I will not see any email.
Note: This is an automated response to your message "[OMPI users] OPEN MPI
data transfer error" sent on 10/22/10 15:19:05.
This is the only
Brian
Most HPC applications are run with one processor and one working thread
per MPI process. In this case, the node is not being used for other work
so if the MPI process does release a processor, there is nothing else
important for it to do anyway.
In these applications, the blocking MPI
pen-mpi.org
Date:
10/19/2010 02:47 PM
Subject:
Re: [OMPI users] a question about [MPI]IO on systemswithout network
filesystem
Sent by:
users-boun...@open-mpi.org
On Thu, Sep 30, 2010 at 09:00:31AM -0400, Richard Treumann wrote:
> It is possible for MPI-IO to be implemented in a way that l
When you use MPI message passing in your application, the MPI library
decides how to deliver the message. The "magic" is simply that when sender
process and receiver process are on the same node (shared memory domain)
the library uses shared memory to deliver the message from process to
I will add to what Terry said by mentioning that the MPI implementation
has no awareness of ordinary POSIX or Fortran disk I/O routines. It
cannot help on those.
Any automated help the MPI implementation can provide would only apply to
MPI_File_xxx disk I/O. These are implemented by the MPI
Amb
It sounds like you have more workers than you can keep fed. Workers are
finishing up and requesting their next assignment but sit idle because
there are so many other idle workers too.
Load balance does not really matter if the choke point is the master. The
work is being done as fast
Re: [OMPI users] Question about Asynchronous collectives
Sent by:
users-boun...@open-mpi.org
Sorry Richard,
what is CC issue order on the communicator?, in particular, "CC", what
does it mean?
2010/9/23 Richard Treumann <treum...@us.ibm.com>
request_1 and request_2 are j
request_1 and request_2 are just local variable names.
The only thing that determines matching order is CC issue order on the
communicator. At each process, some CC is issued first and some CC is
issued second. The first issued CC at each process will try to match the
first issued CC at the
Tony
You are depending on luck. The MPI Standard allows the implementation to
assume that send and recv buffers are distinct unless MPI_IN_PLACE is
used. Any MPI implementation may have more than one algorithm for a given
MPI collective communication operation and the policy for switching
:
>
> users-boun...@open-mpi.org
>
> Please respond to Open MPI Users
>
> Richard Treumann wrote:
>
> Hi Ashley
>
> I understand the problem with descriptor flooding can be serious in
> an application with unidirectional data dependancy. Perhaps we have
>
; to:
>
> Open MPI Users
>
> 09/09/2010 05:37 PM
>
> Sent by:
>
> users-boun...@open-mpi.org
>
> Please respond to Open MPI Users
>
>
> On 9 Sep 2010, at 21:40, Richard Treumann wrote:
>
> >
> > Ashley
> >
> > Can you provide
Ashley
Can you provide an example of a situation in which these semantically
redundant barriers help?
I may be missing something but my statement for the text book would be
"If adding a barrier to your MPI program makes it run faster, there is
almost certainly a flaw in it that is better
I was pointing out that most programs have some degree of elastic
synchronization built in. Tasks (or groups or components in a coupled
model) seldom only produce data.they also consume what other tasks produce
and that limits the potential skew.
If step n for a task (or group or coupled
Ashley's observation may apply to an application that iterates on many to
one communication patterns. If the only collective used is MPI_Reduce,
some non-root tasks can get ahead and keep pushing iteration results at
tasks that are nearer the root. This could overload them and cause some
extra
I am out of the office until 09/07/2010.
I will be out of the office on vacation the week before Labor Day. I will
not see any email.
Note: This is an automated response to your message "[OMPI users] random
IB failures when running medium core counts" sent on 8/30/10 12:22:19.
This is the
Network saturation could produce arbitrary long delays the total data load
we are talking about is really small. It is the responsibility of an MPI
library to do one of the following:
1) Use a reliable message protocol for each message (e.g. Infiniband RC or
TCP/IP)
2) detect lost packets and
It is hard to imagine how a total data load of 41,943,040 bytes could be a
problem. That is really not much data. By the time the BCAST is done, each
task (except root) will have received a single half meg message form one
sender. That is not much.
IMB does shift the root so some tasks may be
As of MPI 2.2 there is no longer a restriction against read access to a
live send buffer. The wording was changed to now prohibit the user to
"modify". You can look the subsection of Communication Modes in chapter 3
but you will need to compare MPI 2.1 and 2.2 carefully to see the change.
- yes I know this should
> not happen, the question is why.
>
> --- On Wed, 11/8/10, Richard Treumann <treum...@us.ibm.com> wrote:
>
> From: Richard Treumann <treum...@us.ibm.com>
> Subject: Re: [OMPI users] MPI_Bcast issue
> To: "Open MPI Users&q
Randolf
I am confused about using multiple, concurrent mpirun operations. If
there are M uses of mpirun and each starts N tasks (carried out under pvm
or any other way) I would expect you to have M completely independent MPI
jobs with N tasks (processes) each. You could have some root in
For reading the data from an isend buffer to cause problems, the
underlying hardware would need to have very unusual characteristic that
the MPI implementation is exploiting. People have imagined hardware
characteristics that could make reading an Isend buffer a problem but I
have never heard
The MPI Standard (in my opinion) should have avoided the word "buffer". To
me, a "buffer" is something you set aside as scratch space between the
application data structures and the communication calls.
In MPI, the communication is done directly from/to the application's data
structures and
Dick Treumann - MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
users-boun...@open-mpi.org wrote on 05/25/2010 12:03:11 AM:
> [image removed]
>
> [OMPI users] About the necessity of
The MPI standard requires that when there is a free running task posting
isends to a task that is not keeping up on receives, the sending task will
switch to synchronous isend BEFORE the receive side runs out of memory and
fails.
There should be no need for the sender to us MPI_Issend
If someone is deciding whether to use complex datatypes or stick with
contiguous ones, they need to look at their own situation. There is no
simple answer. The only thing that is fully predictable is that an MPI
operation, measured in isolation, will be no slower with contiguous data
than with
Bsend does not guarantee to use the attached buffer, Return from MPI_Ibsend
does not guarantee you can modify the application send buffer.
Maybe the implementation would try to optimize by scheduling a nonblocking
send from the apploication buffer that bypasses the copy to the attach
buffer.
An MPI send (of any kind), is defined by "local completion semantics".
When a send is complete, the send buffer may be reused. The only kind of
send that gives any indication whether the receive is posted is the
synchronous send. Neither standard send nor buffered send tell the sender
if the recv
Assume your data is discontiguous in memory and making it contiguous is
not practical (e.g. there is no way to make cells of a row and cells of a
column both contiguous.) You have 3 options:
1) Use many small/contiguous messages
2) Allocate scratch space and pack/unpack
3) Use a derived
The MPI standard says that MPI_Abort makes a "best effort". It also says
that an MPI implementation is free to lose the value passed into MPI_Abort
and deliver some other RC..
The standard does not say that MPI_Abort becomes a valid way to end a
parallel job if it is passed a zero.
To me it
are the messages telling you what the error -might- have been.
On Apr 5, 2010, at 7:01 AM, Richard Treumann wrote:
Why should any software system offer an option which lets the user
hide all distinction between a run that succeeded and one that
failed?
Dick Treumann - MP
Why should any software system offer an option which lets the user hide
all distinction between a run that succeeded and one that failed?
Dick Treumann - MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax
I do not know what the OpenMPI message looks like or why people want to
hide it. It should be phrased to avoid any implication of a problem with
OpenMPI itself.
How about something like this which:
"The application has called MPI_Abort. The application is terminated by
OpenMPI as the
abc def
The MPI_Barrier call in the parent must be on the intercomm returned by the
spawn. The call in the children must be on MPI_COMM_PARENT.
The semantic of an MPI_Barrier call on an intercomm is:
No MPI_Barrier caller in the local group returns until all members of the
remote group have
abc def
When the parent does a spawn call, it presumably blocks until the child
tasks have called MPI_Init. The standard allows some flexibility on this
but at least after spawn, the spawn side must be able to issue
communication calls involving the children and expect them to work.
What you
The program Jonathan offers as an example is valid use of MPI standard
send. With this message size it is fair to assume the implementation is
doing standard send with an eager send. The MPI standard is explicit about
how eager send, as a undercover option for standard send, must work.
When the
A call to MPI_Init allows the MPI library to return any level of thread
support it chooses. This MPI 1.1 call does not let the application say what
it wants and does not let the implementation reply with what it can
guarantee.
If you are using only one MPI implementation and your code will never
...@open-mpi.org
On Mar 3, 2010, at 11:35 AM, Richard Treumann wrote:
> If the application will make MPI calls from multiple threads and
> MPI_INIT_THREAD has returned FUNNELED, the application must be
> willing to take the steps that ensure there will never be concurrent
> c
The caller of MPI_INIT_THREAD says what level of thread safety he would
like to get from the MPI implementation. The implementation says what level
of thread safety it provides.
The implementation is free to provide more or less thread safety than
requested. The caller of MPI_INIT_THREAD should
Tim
MPI is a library providing support for passing messages among several
distinct processes. It offers datatype constructors that let an
application describe complex layouts of data in the local memory of a
process so a message can be sent from a complex data layout or received
into a complex
I cannot resist:
Jaison -
The MPI_Comm_spawn call specifies what you want to have happen. The child
launch is what does happen.
If we can come up with a way to have things happen correctly before we know
what it is that we want to have happen, the heck with this HPC stuff. Lets
get together
The need for a "better" timeout depends on what else there is for the CPU
to do.
If you get creative and shift from {99% MPI_WAIT , 1% OS_idle_process} to
{1% MPI_Wait, 99% OS_idle_process} at a cost of only a few extra
microseconds added lag on MPI_Wait, you may be pleased by the CPU load
MPI standard compliant management of eager send requires that this program
work. There is nothing that says "unless eager limit is set too high/low."
Honoring this requirement in an MPI implementation can be costly. There are
practical reasons to pass up this requirement because most applications
ou would need
> to have a different input communicator for each thread that will
> make an MPI_Comm_spawn call" , i am confused with the term "single
> task communicator"
>
> Best Regards,
> umanga
>
> Richard Treumann wrote:
> It is dangerous to hold a
It is dangerous to hold a local lock (like a mutex} across a blocking MPI
call unless you can be 100% sure everything that must happen remotely will
be completely independent of what is done with local locks & communication
dependancies on other tasks.
It is likely that a MPI_Comm_spawn call in
Dennis
In MPI, you must complete every MPI_Isend by MPI_Wait on the request handle
(or a variant like MPI_Waitall or MPI_Test that returns TRUE). An
un-completed MPI_Isend leaves resources tied up.
I do not know what symptom to expect from OpenMPI with this particular
application error but the
As far as I can see, Jeff's analysis is dead on. The matching order at P2
is based on the order in which the envelopes from P0 and P1 show up at P2.
The Barrier does not force an order between the communication paths P0->P2
vs. P1->P2.
The MPI standard does not even say what "show up" means
processes and determine if
> any are outstanding. It could be accomplished with a single
> MPI_Reduce(sent - received).
>
> Cheers,
> Shaun
>
> Richard Treumann wrote:
> > No - it is not guaranteed. (it is highly probable though)
> >
> > The return from the MPI_
No - it is not guaranteed. (it is highly probable though)
The return from the MPI_Send only guarantees that the data is safely held
somewhere other than the send buffer so you are free to modify the send
buffer. The MPI standard does not say where the data is to be held. It only
says that once
Tee Wen Kai -
You asked "Just to find out more about the consequences for exiting MPI
processes without calling MPI_Finalize, will it cause memory leak or other
fatal problem?"
Be aware that Jeff has offered you an OpenMPI implementation oriented
answer rather than an MPI standard oriented
Santolo
The MPI standard defines reduction operations where the operand/operation
pair has a meaningful semantic. I cannot picture a well defined semantic
for:
999.0 BXOR 0.009. Maybe you can but it is
not an error that the MPI standard leaves out BXOR on
You can use MPI_REQUEST_GET_STATUS as a way to "test" without
deallocation.
I do not understand the reason you would forward the request (as a request)
to another function. The data is already in a specific receive buffer by
the time an MPI_Test returns TRUE so calling the function and passing
There is no synchronization operation in MPI that promises all tasks will
exit at the same time. For MPI_Barrier they will exit as close to the same
time as the implementation can reasonably support but as long as the
application is distributed and there are delays in the interconnect, it is
not
Jeff paraphrased an unnamed source as suggesting that: "any MPI program
that relies on a barrier for correctness is an incorrect MPI application."
. That is probably too strong.
How about this assertion?
If there are no wildcard receives - every MPI_Barrier call is semantically
irrelevant.
It
Hi George
I have run into the argument that in a case where the number of array
elements that will be accessed is == 0 it is "obviously" valid to pass NULL
as the array address. I recognize the argument has merit but I am not clear
that it really requires that an MPI implementation that tries to
I am not 100% sure I understand your situation. It it this?
Process A has an ongoing stream of inputs. For each input unit, A does some
processing and then passes on work to B via a message. B receives the
message from A and does some additional work before sending a message to C.
C receives
One difference is that putting a blocking send before the irecv is a
classic "unsafe" MPI program. It depends on eager send buffering to
complete the MPI_Send so the MPI_Irecv can be posted. The example with
MPI_Send first would be allowed to hang.
The original program is correct and safe MPI.
Vincent
1) Assume you are running an MPI program which has 16 tasks in
MPI_COMM_WORLD, you have 16 dedicated CPUs and each task is single
threaded. (a task is a distinct process, a process can contain one or more
threads) The is the most common traditional model. In this model, when a
task
Hi Robert
Dick Treumann - MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
users-boun...@open-mpi.org wrote on 08/27/2008 11:55:58 AM:
<< snip >>
>
> However from an application point of
Robert -
A return from a blocking send means the application send buffer is
available for reuse. If it is a BSEND, the application buffer could be
available because the message data has been copied to the attached buffer
or because the data has been delivered to the destination. The
Hi Jitendra
Before you worry too much about the inefficiency of using a contiguous
scratch buffer to pack into and send from and a second contiguous scratch
buffer to receive into and unpack from, it would be worth knowing how
OpenMPI processes a discontiguous datatype on your platform.
Hi slimtimmy
I have been involved in several of the MPI Forum's discussions of how
MPI_Cancel should work and I agree with your interpretation of the
standard. By my reading of the standard, the MPI_Wait must not hang and the
cancel must succeed.
Making an MPI implementation work exactly as the
Ron's comments are probably dead on for an application like bug3.
If bug3 is long running and libmpi is doing eager protocol buffer
management as I contend the standard requires then the producers will not
get far ahead of the consumer before they are forced to synchronous send
under the covers
Richard,
>
> You're absolutely right. What a shame :) If I have spent less time
> drawing the boxes around the code I might have noticed the typo. The
> Send should be an Isend.
>
>george.
>
> On Feb 4, 2008, at 5:32 PM, Richard Treumann wrote:
>
> > Hi George
> &g
Hi Gleb
There is no misunderstanding of the MPI standard or the definition of
blocking in the bug3 example. Both bug 3 and the example I provided are
valid MPI.
As you say, blocking means the send buffer can be reused when the MPI_Send
returns. This is exactly what bug3 is count on.
MPI is a
break a particular
> MPI implementation. It doesn't necessarily make this implementation
> non standard compliant.
>
> george.
>
> On Feb 4, 2008, at 9:08 AM, Richard Treumann wrote:
>
> > Is what George says accurate? If so, it sounds to me like OpenMPI
> >
08 02:03:20 PM:
> On Mon, Feb 04, 2008 at 09:08:45AM -0500, Richard Treumann wrote:
> > To me, the MPI standard is clear that a program like this:
> >
> > task 0:
> > MPI_Init
> > sleep(3000);
> > start receiving messages
> >
> > each of tasks 1 to n-
Sorry for typo - The reference is MPI 1.1
Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
- Forwarded by Richard Treumann/Poughkeepsie/IBM on 02/04/2008 01:3
Hi Ron -
I am well aware of the scaling problems related to the standard send
requirements in MPI. I t is a very difficult issue.
However, here is what the standard says: MPI 1.2, page 32 lines 29-37
===
a standard send operation that cannot complete because of lack of buffer
space will
71 matches
Mail list logo
