FW: Re: [Spread-users] Spread Performance

William Isley wmisley at hotmail.com
Tue Apr 27 20:06:00 EDT 2004

Ryan & Yair,

I configured 3 machines, over 100Mbit Ethnet, each PIIIs running Windows XP 
(yes, I know evil Microsoft). 2 machines I configured with Spread Daemons 
with apps I wrote implimenting the Spread API to receive messages. 1 machine 
served as a message sender and connected to one of the other machines Spread 

The best performance I could get was 1.63 MB/sec. The performance with 
having each machine run it's own Spread Daemon actually performed worse than 
having a centralized Spread Daemon. Am I doing something wrong?

My spread.conf (2 of them), contained the following entry:

Spread_Segment {

Is there anything further I can do to squeeze out more performance?

William Isley
IMS Consultants
1250 N. Lakeview Ave, Suite A
Anaheim, CA  92807
Phone:  (714) 693-3505, x21
E-mail: wmisley at imsconsultants.com

>From: Ryan Caudy <caudy at jhu.edu>
>To: spread-users <spread-users at lists.spread.org>
>Subject: Re: [Spread-users] Spread Performance
>Date: Tue, 27 Apr 2004 14:53:54 -0400
>[Hope this doesn't come out garbled, but I forgot to CC to the list first 
>My comments are inlined below.
>Good luck,
>William Isley wrote:
> > Hi Spread Group,
> >
> > I plan to use spread to reliably multicast Gigabytes of files to 40+ 
>machines. I have tried several configurations, and with only 5 clients 
>receiving files (rebuilt from messages sent over Spread), the best data 
>throughput I can achieve is 3 MB/sec. I am required to achieve at least 6 
> >
>What is your network environment?  I'll assume a LAN with 100 Mbps 
> > I have tried running the Spread Daemon on a separate server, on the 
>message sender, and a message receiver. I get the best performance with the 
>Spread Daemon running on the message receiver. I am using the SAFE message 
>transport type, but have tried the UNRELIABLE message transport type with 
>negligable performance gain.
> >
>I'd recommend that you run Spread daemons on all of the hosts that have 
>Spread clients (sender and all receivers in your system).  The idea here is 
>to maximize the amount of data that is transferred over your network as 
>multicast/broadcast.  Otherwise, you end up with the same unicast data 
>going over the network several times.  Multicast is only done between 
>daemons in the same segment.
>I don't know for sure what your application's semantics are, but it sounds 
>to me like you don't need SAFE messages.  For a one-to-many system like you 
>describe, FIFO should be sufficient.  The application should be easier to 
>develop with service type FIFO (or higher) than RELIABLE or UNRELIABLE.
> > I have tried scheduling Spread to run with Realtime scheduling. The 
>performance gain was negligable. I am running all of this software on 
> >
>I wouldn't be surprised if you didn't get all the performance you want on 
>Windows, although giving it high priority as you've described should 
>certainly help.  Be careful to make sure that the clients get plenty of CPU 
>time also, so that the sender can send fast enough, and so that the 
>receivers can keep up.
> > I tried running the Spread Daemon on a dual Xeon processor machine. The 
>result is that the Spread clients loose there connection under heavy load. 
>The other machines in the configuration single 1GHz processor machines.
> >
>Again, I'd recommend that you use many Spread daemons, not just one. You 
>may need to tweak the flow control a bit, but I think you'll be ok with a 
>network like I described.  Keep in mind that if your sender outpaces your 
>receivers, Spread will eventually disconnect them.
> > I need to squeeze more out of Spread than 3 MB/sec. The website 
>advertises 8 MB/sec. What can I do to better this performance? Are there 
>any changes I can make to the Spread.conf file that will increase the 
>performance? Is it possible to run multiple Spread Daemons? How to I 
>configure this system if this is an option and what is the benefit?
> >
>It is not only possible, but almost always desirable to run multiple Spread 
>daemons.  To do so, the only major change is to the Spread_Segment section 
>of the spread.conf file.  Basically, instead of using the configuration for 
>a single daemon (usually just a daemon on localhost using the localhost 
>broadcast address), you use a configuration more like
>Spread_Segment xxx.yyy.zzz.255:4803 {
>   hostname1  xxx.yyy.zzz.11
>   hostname2  xxx.yyy.zzz.12
>   hostname3  xxx.yyy.zzz.13
>This configuration assumes you have a /24, and that you're using broadcast 
>instead of multicast.  You could replace the (/24) broadcast address 
>xxx.yyy.zzz.255 with the appropriate one for your network, or simply use a 
>multicast addres instead if your network supports IP multicast.  Do NOT 
>include the localhost address in your configuration.  Note that it may be 
>necessary to specify at each host the hostname it is using (using spread -n 
>hostname), depending on how your machines are configured.
>I've descibed the benefits of using multiple daemons above.
> > I have looked at TIBCO's SmartPGM, which is not viable due to cost. 
>JGroups advertises performance below that of Spread.
> >
> > Any help from anyone would be apprecieate,
> >
> > William Isley
> > IMS Consultants
> > 1250 N. Lakeview Ave, Suite A
> > Anaheim, CA  92807
> > Phone:  (714) 693-3505, x21
> > E-mail: wmisley at imsconsultants.com
> >
> > _________________________________________________________________
> >
> >> From must-see cities to the best beaches, plan a getaway with the 
> >
> >
> > Travel Guide! http://special.msn.com/local/springtravel.armx
> >
> >
> > _______________________________________________
> > Spread-users mailing list
> > Spread-users at lists.spread.org
> > http://lists.spread.org/mailman/listinfo/spread-users
> >
>Ryan W. Caudy
>Center for Networking and Distributed Systems
>Department of Computer Science
>Johns Hopkins University
>Spread-users mailing list
>Spread-users at lists.spread.org

Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! 

More information about the Spread-users mailing list