Yeah, that is "normal". It has to do with unexpected messages.
When you have procs running at significantly different speeds, the
various operations get far enough out of sync that the memory consumed
by recvd messages not yet processed grows too large.
Instead of sticking barriers into your code, you can have OMPI do an
internal sync after every so many operations to avoid the problem.
This is done by enabling the "sync" collective component, and then
adjusting the number of operations between forced syncs.
Do an "ompi_info --params coll sync" to see the options. Then set the
coll_sync_priority to something like 100 and it should work for you.
Ralph
On Nov 10, 2009, at 2:45 PM, Glembek Ondřej wrote:
Hi,
I am using MPI_Reduce operation on 122880x400 matrix of doubles. The
parallel job runs on 32 machines, each having different processor in
terms of speed, but the architecture and OS is the same on all
machines (x86_64). The task is a typical map-and-reduce, i.e. each
of the processes collects some data, which is then summed
(MPI_Reduce w. MPI_SUM).
Having different processors, each of the jobs comes to the
MPI_Reduce in different time.
The *first problem* came when I called MPI_Reduce on the whole
matrix. The system ended up with *MPI_ERR_OTHER error*, each time on
different rank. I fixed this problem by chunking up the matrix into
2048 submatrices, calling MPI_Reduce in cycle.
However *second problem* arose --- MPI_Reduce hangs up... It
apparently gets stuck in some kind of dead-lock or something like
that. It seems that if the processors are of similar speed, the
problem disappears, however I cannot provide this condition all the
time.
I managed to get rid of the problem (at least after few non-
problematic iterations) by sticking MPI_Barrier before the
MPI_Reduce line.
The questions are:
1) is this a usual behavior???
2) is there some kind of timeout for MPI_Reduce???
3) why does MPI_Reduce die on large amount of data if the system has
enough address space (64 bit compilation)
Thanx
Ondrej Glembek
--
Ondrej Glembek, PhD student E-mail: glem...@fit.vutbr.cz
UPGM FIT VUT Brno, L226 Web: http://www.fit.vutbr.cz/~glembek
Bozetechova 2, 612 66 Phone: +420 54114-1292
Brno, Czech Republic Fax: +420 54114-1290
ICQ: 93233896
GPG: C050 A6DC 7291 6776 9B69 BB11 C033 D756 6F33 DE3C
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
