Hi again Jeff,
> No, not necessarily. Check out the sidebar entitled "To block or not
> to block" in this column for an explanation:
>
> http://cw.squyres.com/columns/2004-02-CW-MPI-Mechanic.pdf
>
> Short version: if you are sending a short message, you may actually be
> sending many times before your receive completes (it's a parallel race
> condition). If you're trying to simply match a single send and a
> single receive, you might want to use MPI_SENDRECV or a pattern similar
> to:
>
> MPI_Irecv(...)
> MPI_Isend(...);
> MPI_Waitall(...);
>
I see, thanks for this info.
Does the MPI_SENDRECV pattern rely on each node receiving a response to
a send, ie., for every send there is one recv.
> - Do the slaves know if the message they send is going to generate a
> response from the master?
No
> - Does the slave need to block while waiting for that ack, or can it
> continue to do other work?
Each slave has 3 threads
1. one for interfacing with mpi (checking for incoming and outgoing
messages) - this is the thread I described previously.
2. one main thread for processing incoming messages.
3. A thread which generates the events to send to the master
So I guess the answer is it can do other work.
> Check for other OS kinds of slowness -- are you overloading nodes (more
> processes than processors)? Are you doing significant I/O? Is there a
> lot of message passing traffic? And so on.
>
The problem only occurs when I overload ie., with more than one slave
per node (on a one processor node).
Unfortunately I want to be able to run experiments with more slaves than
I have CPUs :)
Is overloading known to cause serious slow down or is there something I
can do about it?
Thanks again
Mike
mhl_at_[hidden]
http://www.cs.nott.ac.uk/~mhl/
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
|
