Thank you for your answer. Actually, I used the term UDP to show the non-connection oriented messaging. TCP creates connection between two parties (who communicate) but in UDP a message can be sent to any IP/port where a process/thread is listening to, and if the process is busy in doing something, all the received messages are queued for it and when ever it calls the recv function one message is taken from the queue.
I am implementing a distributed algorithm that will provide communication sensitive load balancing for computational loads. For example, if we have 10 nodes each containing 10 cores (100 cores in total). So when MPI application will start (let say with 1000) processes (more than 1 process per core) then I will run my distributed algorithm MPI_Balance (sorry for giving MPI_ prefix as it is not a part of MPI, but I am trying to make it the part of MPI ;) ). So that algorithm will take those processes that communicate more in the same node (keeping the computational load on 10 cores on that node balanced).
So that was the little bit explanation. So for that my distributed algorithm requires that some processes communicate with each other to collaborate on something. So I need a kind of messaging that I explained above. It is kind of UDP messaging (no connection before sending a message, and message is always queued on the receiver's side and sender is not blocked, it just sends the message and the receiver takes it when it gets free from other task).
I have tried to use the combination of MPI_Send, MPI_Recv, MPI_Iprobe, MPI_Isend, MPI_Irecv, MPI_Test etc, but I am not getting that thing that I am looking for. I think MPI should also provide that way. May be it is not in my knowledge. That's why I am asking the experts. I am still looking for it :(
thanks and regards,
PhD Topic: Parallel Computing (Optimal composition of parallel programs and runtime support).
From: Jeff Squyres <jsquyres_at_[hidden]>
To: mudassarm30_at_[hidden]; Open MPI Users <users_at_[hidden]>
Cc: "linux_at_[hidden]" <linux_at_[hidden]>
Sent: Monday, November 21, 2011 6:07 PM
Subject: Re: [OMPI users] UDP like messaging with MPI
MPI defines only reliable communications -- it's not quite the same thing as UDP.Â
Hence, if you send something, it is guaranteed to be able to be received.Â UDP may drop packets whenever it feels like it (e.g., when it is out of resources).
Most MPI implementations will do some form of buffering of unexpected receives.Â So if process A sends message X to process B, if B hasn't posted a matching receive for message X yet, B will likely silently accept the message under the covers and buffer it (or at least buffer part of it).Â Hence, when you finally post the matching X receive in B, whatever of X was already received will already be there, but B may need to send a clear-to-send to A to get the rest of the message.
Specifically: if X is "short", A may eagerly send the whole message to B.Â If X is "long", A may only send the first part of B and wait for a CTS before sending the rest of it.
MPI implementations typically do this in order to conserve buffer space -- i.e., if A sends a 10MB message, there's no point in buffering it at B until the matching receive is made and the message can be received directly into the destination 10MB buffer that B has made available.Â If B accepted the 10MB X early, it would cost an additional 10MB to buffer it.Â Ick.
Alternatively, what I think Lukas was trying to suggest was that you can post non-blocking receives and simply test for completion later.Â This allows MPI to receive straight into the target buffer without intermediate copies or additional buffers.Â Then you can just check to see when the receive(s) is(are) done.
On Nov 19, 2011, at 10:47 AM, Mudassar Majeed wrote:
> I know about tnÄ±s functÄ±ons, they special requirements like the mpi_irecv call should be made in every process. My processes should not look for messages or implicitly receive them. But messages shuddering go into their msg queues and retrieved when needed. Just like udp communication.
> users mailing list
For corporate legal information go to: