Sorry, I meant to say:- on each node there is 1 listener and 1 worker.- all workers act together when any of the listeners send them a request.- currently I must use an extra clearinghouse process to receive from any of the listeners and bcast to workers, this is unfortunate because of the potential scaling issues
I think you have answered this in that I must wait for MPI-3's non-blocking collectives.
Can anyone suggest another way? I don't like the serial clearinghouse approach.
--- On Wed, 4/5/11, Jeff Squyres <jsquyres_at_[hidden]> wrote:
From: Jeff Squyres <jsquyres_at_[hidden]>
Subject: Re: [OMPI users] is there an equiv of iprove for bcast?
To: randolph_pullen_at_[hidden], "Open MPI Users" <users_at_[hidden]>
Received: Wednesday, 4 May, 2011, 11:19 AM
I don't quite understand your architecture enough to answer your question. E.g., someone pointed out to me off-list that if you only have 1 listener, a send is effectively the same thing as a broadcast (for which you could test/wait on a non-blocking receive, for example).
MPI broadcasts only work on fixed communicators -- meaning that you effectively have to know the root and the receivers ahead of time. If the receivers don't know who the root will be beforehand, that's unfortunately not a good match for the MPI_Bcast operation.
On May 3, 2011, at 4:07 AM, Randolph Pullen wrote:
> From: Randolph Pullen <randolph_pullen_at_[hidden]>
> Subject: Re: Re: [OMPI users] is there an equiv of iprove for bcast?
> To: users_at_open-mpi.or
> Received: Monday, 2 May, 2011, 12:53 PM
> Non blocking Bcasts or tests would do it.
> I currently have the clearing-house solution working but it is unsatisfying because of its serial node. - As it scales it will overload this node.
> The problem rephrased:
> Instead of n*2 processes, I am having to use n*2+1 with the extra process serially receiving listener messages on behalf of the workers before transmitting these messages to workers in its comm_group.
> Is there a way to Bcast directly from each listener to the worker pool? (listeners must monitor their ports most of the time and cant participate in global bcasts)
> Not knowing which listener is going to transmit prevents the correct comm_group being used with Bcast calls.
> --- On Sat, 30/4/11, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> From: Jeff Squyres <jsquyres_at_[hidden]>
> Subject: Re: [OMPI users] is there an equiv of iprove for bcast?
> To: randolph_pullen_at_[hidden], "Open MPI Users" <users_at_[hidden]>
> Received: Saturday, 30 April, 2011, 7:17 AM
> On Apr 29, 2011, at 1:21 AM, Randolph Pullen wrote:
> > I am having a design issue:
> > My server application has 2 processes per node, 1 listener and 1 worker.
> > Each listener monitors a specified port for incoming TCP connections with the goal that on receipt of a request it will distribute it over the workers in a SIMD fashion.
> > My problem is this: how can I get the workers to accept work from any of the listeners?
> > Making a separate communicator does not help as the sender is unknown. Other than making a serial 'clearing house' process I cant think of a way - Iprobe for Bcast would be useful.
> I'm not quite sure I understand your question.
> There currently is no probe for collectives, but MPI-3 has non-blocking collectives which you could MPI_Test for. There's a 3rd party library implementation called libNBC (non-blocking collectives) that you could use until such things become natively available.
> Jeff Squyres
> For corporate legal information go to:
> users mailing list
For corporate legal information go to: