[Spread-users] 1225

koorosh.alahiari at ids.allianz.com koorosh.alahiari at ids.allianz.com
Thu Mar 7 04:47:06 EST 2002


I understand your point on flow control. I am
trying to workout what is happening inside spread
to account for the considerable difference in
processing speed between sending & receiving.

My Sender & Receiver both reside on the same
machine and are bare-bone clients.

When a sender is sending spread is receiving
(from the sender) that is very fast. BUT when spread
is distributing the message (even to just one client)
it seems to be much slower (eventhough the whole
process is still v. fast).

Is the overhead arising from multicasting (assuming
my clients don't cause it & there's no net. latency)?
I would appreciate being educated on this topic.

Regards, Koorosh

                    Jonathan Stanton                                                                                                    
                    <jonathan at cnds.jhu.edu>          To:     koorosh.alahiari at ids.allianz.com                                           
                    Sent by:                         cc:     spread-users at lists.spread.org                                              
                    spread-users-admin at lists.        Subject:     Re: [Spread-users] 1225                                               
                    07/03/02 08:23                                                                                                      

On Wed, Mar 06, 2002 at 06:39:43PM +0100, koorosh.alahiari at ids.allianz.com
> Hi All,
> I have done some performance testing & find that
> Sending is a little over twice as fast as
> Receiving and this is why Rceivers
> get shot down by spread since eventually
> spread is going to reach its backlog
> limit.
> My Senders & Receivers (one of each)
> do very little else but sending and receiving
> in a tight loop.
> Does this make sense?

Yes. In any application you will need to do some flow-control or
synchronization between the senders and receivers unless you want to drop

Since spread is designed from a reliable transpot point-of-view it
doesn't drop messages. Spread does support "unreliable" messages which can
be dropped, but it currently doesn't drop them when the receive queue fills
up (that would not be hard to chagne though)

So you need to include flow control in whatever application you are
designing and then the problem should go away.

Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science
Johns Hopkins University

Spread-users mailing list
Spread-users at lists.spread.org

More information about the Spread-users mailing list