Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!emory!hubcap!fpst
From: jet@karazm.math.uh.edu ("J. Eric Townsend")
Newsgroups: comp.parallel
Subject: Re: iPSC/860 Communication Performance
Message-ID: <1991Apr23.214629.4085@menudo.uh.edu>
Date: 23 Apr 91 21:46:29 GMT
References: <1991Apr23.123808.10313@hubcap.clemson.edu>
Sender: usenet@menudo.uh.edu (USENET News System)
Organization: University of Houston -- Department of Mathematics
Lines: 27
Approved: parallel@hubcap.clemson.edu
Nntp-Posting-Host: karazm.math.uh.edu

In article <1991Apr23.123808.10313@hubcap.clemson.edu> wangjw@cs.purdue.edu () writes:
>every other node. The everage elapsed time from sending to receiving for 
>broadcast call is around 1/2 of the looping method for message length of 
>500. This is quite good since it really speedups the communication. It

The iPSC message passing software has a magic size of 100bytes.  Anything
<=100 bytes only takes one message send.  Anything >100bytes takes *three*
message sends, to insure that there is enought space in the receiving buffer.

I would suggest that you do timings of both messages <100bytes and messages of
 >100bytes.

Also, look closely at using FORCETYPE in your message type.  If you
*know*  you have room to receive a message, the sender can use
FORCETYPE and the "is there room?" message exchange does not happen.


--
J. Eric Townsend - jet@uh.edu - bitnet: jet@UHOU - vox: (713) 749-2120
Skate UNIX or bleed, boyo...
(UNIX is a trademark of Unix Systems Laboratories).

-- 
=========================== MODERATOR ==============================
Steve Stevenson                            {steve,fpst}@hubcap.clemson.edu
Department of Computer Science,            comp.parallel
Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell