On Tue, 26 Aug 2003, Jeff Squyres wrote:
> A quick look at this code (transport.cc) shows that it is not safe -- it
> loops over MPI_Send's without any corresponding MPI_Recv's. More
> specifically, it assumes buffering of the MPI layer of which the sysv and
> usysv RPI's do not provide much/any. It works with TCP because TCP
> provides (by default) 64k of buffering. I'd suggest mailing the DaSSF
> author(s) and let them know about this problem.
>
Thanks for the response. My more immediate problem was why the
lamtests would not run with MODES="sysv usysv" on sparc-U2,U60. This
looks like a library problem peculiar to Linux/Sparc on Ultra systems.
What happens is this:
1. On SS20-Linux-SMP (NOT ultra), everything is fine;
2. On U2-Linux-SMP (sun4u based system), MODE=sysv hangs when
make check MODES="sysv"
3. Here's why: On U2, U60, but not SS20, the system call
semctl(semid,x,SETVAL,cmd) silently succeeds without setting
any value but zero into the semaphore (as ipcs command verifies).
4. semctl(semid,0,SETALL,cmd) works fine, though.
My best guess is that the problem is in sys-libs/glibc-2.3.1-r4 (as built
for GenToo Linux on sparc), but it is definitely not a LAM-MPI problem.
> Troll through the mailing lists for past discussions on this topic -- a
> quick check to ensure that an MPI program is safe/portable is to replace
> all MPI_Send's with MPI_Ssends.
Thanks for the tip.
>
> Also, as you correctly determined, DaSSF's helper scripts assume MPICH's
> mpirun format.
>
It's easy to change DaSSF to use any call you like. Right now, I have
just been fixing things up by hand as I go because I am getting a feel
for what it would take to swap in LAM-MPI for MPICH, and whether I would
benefit from doing so.
I lean toward LAM because it seems to be a much more active project,
and it's certainly more comprehensible [code]. (Also, many years ago I
used
to work for Frank Prosser, but that's another story....)
Regards,
--
Ferris McCormick (P44646, MI) <fmccor_at_[hidden]>
Phone: (703) 392-0303
Fax: (703) 392-0401
|
