Newsgroups: comp.parallel.pvm
From: rff@inf.rl.ac.uk (Ronald Fowler)
Subject: Re: pvm message passing timing
Organization: Rutherford Appleton Laboratory
Date: 11 Aug 1995 08:05:41 GMT
Message-ID: <40f30l$1fho@unixfe.rl.ac.uk>

In article jh7@nntpd.lkg.dec.com, eve_li@btgmax.zko.dec.com (Eve Li) writes:
>Erik Demaine (edemaine@ug.cs.dal.ca) wrote:
>: clock (user and system time) does *not* include the extra time to wait
>: for a message to be received in typical message-passing (e.g., PVM), because
>: the method used is blocking (which takes wall-clock time, but no CPU time)
>: and not polling.  Thus, gettimeofday (or equivalent) _must_ be used to take
>
>Is this really true? Does PVM really using blocking message-passing? 
>How about pvm-psend, pvm-precv? 

In my limited experience with pvm3.3.8 on SUNMP/SGI5 with Ethernet,
elasped time is very similar to CPU time in pvmfsend/pvmfrecv,
indicating that the blocking isn't very effective if it is used.
I have been trying to see if much overlap of communication and
computation is possible, with rather disappointing results so far.

>The documentation says:
>	The pvm_psend routine is asynchronous.  Computation on the
>       sending processor resumes as soon as the  buffer  is  safe
>       for  reuse.  This is in contrast to synchronous communica-
>       tion, during which computation on  the  sending  processor
>       halts  until  the  matching  receive  is  executed  by the
>       receiving processor.
>
>
>My guess is that gettimeofday is still better when pvm-psend/pvm-precv
>are used because pvm_psend could block if there are too much data to send
>or recv. Thus, it takes more wall clock time than cpu time. 
>
>any comments? 
> 

If RouteDirect is used it seems quite possible to get blocking in the
send if the receiver is busy.

Ron Fowler







