LAM/MPI logo

LAM/MPI General User's Mailing List Archives

  |   Home   |   Download   |   Documentation   |   FAQ   |   all just in this list

From: Brian W. Barrett (brbarret_at_[hidden])
Date: 2002-09-04 22:25:38


On Wed, 4 Sep 2002, Jose Luis Bosque wrote:

> I am working with a cluster with 8 Pc's, and I need to measure the
> overhead time of the MPI_Recv function, in a point to point
> communication, for messages of different sizes. With messages size under
>
> 60000 bytes there are no problems. But when the messages are longger,
> the MPI_Recv functions as a synchronous function, and the values of
> overhead time are not correct. Is there any way to change this limit ?

Everything that Roberto said is true - you can change the cross-over point
at configure time. This will push back the point at which you see the
change from "fire and forget" short messages to "request to send" longer
messages.

However, I question your logic in doing this (and therefore the value of
the benchmark data you will produce). There are performance changes that
result from moving the short/long switch-over point. 64k is the default
because it generally matches the maximum buffer size for a TCP connection.
This is one of those points where bigger is not necessarily better for a
real application. LAM makes some assumptions about sending short messages
that definitely would not be true for very large message sizes. This
would cause "much badness" for many applications.

So, setting the cross-over point to a very big number for normal MPI use
is obviously not a "good thing". So you don't want to do this in a
benchmark suite - benchmarks that flagrantly bend normal operating
conditions are even less useful than normal benchmarks :).

I'm not really sure what you mean by overhead - do you mean the entire
time that the benchmark app is in the MPI function but not actually
sending data? Or do you mean the entire time that the benchmark app is in
the MPI function? Or something entirely different? I'm sure that we can
come up with a way for you to get your numbers, but I'm not sure what you
need. Let me know, and I'll help you come up with something that will
more accurately reflect the operating conditions of LAM/MPI.

Brian

-- 
  Brian Barrett
  LAM/MPI developer and all around nice guy
  Have a LAM/MPI day: http://www.lam-mpi.org/
_______________________________________________
This list is archived at http://www.lam-mpi.org/MailArchives/lam/