Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI users] MPI_Bcast issue
From: David Zhang (solarbikedz_at_[hidden])
Date: 2010-08-07 22:34:16

In particular, intercommunicators

On 8/7/10, Aurélien Bouteiller <bouteill_at_[hidden]> wrote:
> You should consider reading about communicators in MPI.
> Aurelien
> --
> Aurelien Bouteiller, Ph.D.
> Innovative Computing Laboratory, The University of Tennessee.
> Envoyé de mon iPad
> Le Aug 7, 2010 à 1:05, Randolph Pullen <randolph_pullen_at_[hidden]> a
> écrit :
>> I seem to be having a problem with MPI_Bcast.
>> My massive I/O intensive data movement program must broadcast from n to n
>> nodes. My problem starts because I require 2 processes per node, a sender
>> and a receiver and I have implemented these using MPI processes rather
>> than tackle the complexities of threads on MPI.
>> Consequently, broadcast and calls like alltoall are not completely
>> helpful. The dataset is huge and each node must end up with a complete
>> copy built by the large number of contributing broadcasts from the sending
>> nodes. Network efficiency and run time are paramount.
>> As I don’t want to needlessly broadcast all this data to the sending nodes
>> and I have a perfectly good MPI program that distributes globally from a
>> single node (1 to N), I took the unusual decision to start N copies of
>> this program by spawning the MPI system from the PVM system in an effort
>> to get my N to N concurrent transfers.
>> It seems that the broadcasts running on concurrent MPI environments
>> collide and cause all but the first process to hang waiting for their
>> broadcasts. This theory seems to be confirmed by introducing a sleep of
>> n-1 seconds before the first MPI_Bcast call on each node, which results
>> in the code working perfectly. (total run time 55 seconds, 3 nodes,
>> standard TCP stack)
>> My guess is that unlike PVM, OpenMPI implements broadcasts with broadcasts
>> rather than multicasts. Can someone confirm this? Is this a bug?
>> Is there any multicast or N to N broadcast where sender processes can
>> avoid participating when they don’t need to?
>> Thanks in advance
>> Randolph
>> _______________________________________________
>> users mailing list
>> users_at_[hidden]

Sent from my mobile device
David Zhang
University of California, San Diego