FW: Re: [Spread-users] Spread Performance
William Isley
wmisley at hotmail.com
Wed Apr 28 14:58:14 EDT 2004
Below is my configuration file for my spmonitor issue:
# Blank lines are permitted in this file.
# spread.conf sample file
#
# questions to spread at spread.org
#
#MINIMAL REQUIRED FILE
#
# Spread should work fine on one machine with just the uncommented
# lines below. The rest of the file documents all the options and
# more complex network setups.
#
# This configures one spread daemon running on port 4803 on localhost.
Spread_Segment 192.168.1.255:4803 {
Machine3 192.168.1.169
Machine4 192.168.1.141
Machine5 192.168.1.21
}
# Spread options
#---------------------------------------------------------------------------
#---------------------------------------------------------------------------
#Set what internal Spread events are logged to the screen or file
# (see EventLogFile).
# Default setting is to enable PRINT and EXIT events only.
#The PRINT and EXIT types should always be enabled. The names of others are:
# EXIT PRINT DEBUG DATA_LINK NETWORK PROTOCOL SESSION
# CONFIGURATION MEMBERSHIP FLOW_CONTROL STATUS EVENTS
# GROUPS MEMORY SKIPLIST ALL NONE
# ALL and NONE are special and represent either enabling every type
# or enabling none of them.
# You can also use a "!" sign to negate a type,
# so { ALL !DATA_LINK } means log all events except data_link ones.
DebugFlags = { PRINT EXIT }
#Set whether to log to a file as opposed to stdout/stderr and what
# file to log to.
# Default is to log to stdout.
#
#If option is not set then logging is to stdout.
#If option is set then logging is to the filename specified.
# The filename can include a %h or %H escape that will be replaced at
runtime
# by the hostname of the machine upon which the daemon is running.
# For example "EventLogFile = spreadlog_%h.log" with 2 machines
# running Spread (machine1.mydomain.com and machine2.mydomain.com) will
# cause the daemons to log to "spreadlog_machine1.mydomain.com.log" and
# "spreadlog_machine2.mydomain.com.log" respectively.
EventLogFile = C:\testlog.out
#Set whether to add a timestamp in front of all logged events or not.
# Default is no timestamps. Default format is "[%a %d %b %Y %H:%M:%S]".
#If option is commented out then no timestamp is added.
#If option is enabled then a timestamp is added with the default format
#If option is enabled and set equal to a string, then that string is used
# as the format string for the timestamp. The string must be a valid time
# format string as used by the strftime() function.
EventTimeStamp
# or
#EventTimeStamp = "[%a %d %b %Y %H:%M:%S]"
#Set whether to allow dangerous monitor commands
# like "partition, flow_control, or kill"
# Default setting is FALSE.
#If option is set to false then only "safe" monitor commands are allowed
# (such as requesting a status update).
#If option is set to true then all monitor commands are enabled.
# THIS IS A SECURTIY RISK IF YOUR NETWORK IS NOT PROTECTED!
DangerousMonitor = true
#Set handling of SO_REUSEADDR socket option for the daemon's TCP
# listener. This is useful for facilitating quick daemon restarts (OSes
# often hold onto the interface/port combination for a short period of time
# after daemon shut down).
#
# AUTO - Active when bound to specific interfaces (default).
# ON - Always active, regardless of interface.
# SECURITY RISK FOR ANY OS WHICH ALLOW DOUBLE BINDS BY DIFFERENT
USERS
# OFF - Always off.
#SocketPortReuse = AUTO
#Sets the runtime directory used when the Spread daemon is run as root
# as the directory to chroot to. Defaults to the value of the
# compile-time preprocessor define SP_RUNTIME_DIR, which is generally
# "/var/run/spread".
#RuntimeDir = /var/run/spread
#Sets the unix user that the Spread daemon runs as (when launched as
# the "root" user). Not effective on a Windows system. Defaults to
# the user and group "spread".
#DaemonUser = spread
#DaemonGroup = spread
#Set the list of authentication methods that the daemon will allow
# and those which are required in all cases.
# All of the methods listed in "RequiredAuthMethods" will be checked,
# irregardless of what methods the client chooses.
# Of the methods listed is "AllowedAuthMethods" the client is
# permitted to choose one or more, and all the ones the client chooses
# will also be checked.
#
# To support older clients, if NULL is enabled, then older clients can
# connect without any authentication. Any methods which do not require
# any interaction with the client (such as IP) can also be enabled
# for older clients. If you enable methods that require interaction,
# then essentially all older clients will be locked out.
#
#The current choices are:
# NULL for default, allow anyone authentication
# IP for IP based checks using the spread.access_ip file
#RequiredAuthMethods = " "
#AllowedAuthMethods = "NULL"
#Set the current access control policy.
# This is only needed if you want to establish a customized policy.
# The default policy is to allow any actions by authenticated clients.
#AccessControlPolicy = "PERMIT"
# network description line.
# Spread_Segment <multicast address for subnet> <port> {
# port is optional, if not specified the default 4803 port is used.
#Spread_Segment 127.0.0.255:4803 {
# either a name or IP address. If both are given, than the name is taken
# as-is, and the IP address is used for that name.
# localhost 127.0.0.1
#}
# repeat for next sub-network
#Spread_Segment x.2.2.255 {
# other1 128.2.2.10
# 128.2.2.11
# other3.my.com
#}
# Spread will feel free to use broadcast messages within a sub-network.
# if you do not want this to happen, you should specify your machines on
# different logical sub-networks.
# IP-Multicast addresses can also be used as the multicast address for
# the logical sub-network as in this example. If IP-multicast is supported
# by the operating system, then the messages will only be received
# by those machines who are in the group and not by all others in the same
# sub-network as happens with broadcast addresses
#Spread_Segment 225.0.1.1:3333 {
# mcast1 1.2.3.4
# mcast2 1.2.3.6
#}
# Multi-homed host setup
#
# If you run Spread on hosts with multiple interfaces you may want to
# control which interfaces Spread uses for client connections and for
# the daemon-to-daemon (and monitor control) messages. This can be done
# by adding an extra stanza to each configured machine.
#
#Sample:
#
#Spread_Segment 225.0.1.1 {
# multihomed1 1.2.3.4 {
# D 192.168.0.4
# C 1.2.3.4 }
# multihomed2 1.2.3.5 {
# D 192.168.0.5
# C 1.2.3.5
# C 127.0.0.1 }
# multihomed3 1.2.3.6 {
# 192.168.0.6
# 1.2.3.6 }
#}
# This configuration sets up three multihomed machines into a Spread
segment.
# The first host has a 'main' IP address of 1.2.3.4 and listens for client
# connections only on that interface. All daemon-to-daemon UDP multicasts
and
# the tokens and any monitor messages must use the 192.168.0.4 interface.
# The second host multihomed2 has a similar setup, except it also listens
for
# client connections on the localhost interface as well as the 1.2.3.5
interface.
# If you make any use of the extra interface stanza ( a { } block ) then you
must
# explicitly configure ALL interfaces you want as Spread removes all
defaults when
# you use the explicit notation.
# The third multihomed3 host uses a shorthand form of omitting the D or C
option and
# just listening for all types of traffic and events on both the 192.168.0
and 1.2.3
# networks. If no letter is listed before the interface address then ALL
types of
# events are handled on that interface.
>From: Ryan Caudy <caudy at jhu.edu>
>To: William Isley <wmisley at hotmail.com>
>CC: jschultz at spreadconcepts.com, spread-users at lists.spread.org
>Subject: Re: FW: Re: [Spread-users] Spread Performance
>Date: Wed, 28 Apr 2004 14:55:37 -0400
>
>Please send your configuration file to the list.
>
>--Ryan
>
>William Isley wrote:
>
>>I am headed down the path of using a separate Spread Daemon for each
>>individual group messager. I still don't get the performance I need
>>however. I plan to tweek the token passing timeouts and message
>>buffersizes of the daemon.
>>
>>I am having a problem running the spmonitor. First, I did not see a
>>project file to build this under Windows, so I created one. When I run the
>>monitor I get the following error:
>>
>>Conf_init: using file: spread.conf
>>DL_init_channel: socket error for port 6543
>>Exit caused by Alarm(EXIT)
>>
>>The command I used to run the monitor is spread -n Machine5 where Machine5
>>is defined as the Spread Daemon running on the local machine in
>>spread.conf. I tried telling the monitor to use port 4803, but this did
>>not resolve the issue. I have dangerous messages enabled in the
>>spread.conf file.
>>
>>I am trying to run the monitor against a Spread Daemon running on local
>>host. Does anyone know why I get this error?
>>
>>William
>>
>>
>>>From: John Schultz <jschultz at spreadconcepts.com>
>>>To: "spread-users at lists.spread.org" <spread-users at lists.spread.org>
>>>Subject: Re: FW: Re: [Spread-users] Spread Performance
>>>Date: Wed, 28 Apr 2004 12:34:07 -0400
>>>
>>>Ciprian Tutu wrote:
>>>
>>>>Hi,
>>>>
>>>>WI> I configured 3 machines, over 100Mbit Ethnet, each PIIIs running
>>>>Windows XP
>>>>WI> (yes, I know evil Microsoft). 2 machines I configured with Spread
>>>>Daemons
>>>>WI> with apps I wrote implimenting the Spread API to receive messages. 1
>>>>machine
>>>>WI> served as a message sender and connected to one of the other
>>>>machines Spread
>>>>WI> Daemons.
>>>>
>>>>Honestly I would configure one daemon on each of your 3 machines and
>>>>have
>>>>each client application (including the sender) connect to their local
>>>>daemon. This way you really let spread handle _all_ the traffic of the
>>>>experiment.
>>>>
>>>>Add your 3rd daemon to the config file on each machine and give it a
>>>>try.
>>>>
>>>
>>>I agree with this recommendation. You really want Spread running on
>>>every machine with processes that could call SP_connect. Usually your
>>>SP_connect call should be a hardcode to <port_num>@localhost.
>>>
>>>Another thing to check is whether or not your configuration is losing
>>>messages at all. If the network is losing tokens intermittently but
>>>often this would slow you down. You can detect this by examining the
>>>state of all the daemons using spmonitor and looking at the retrans
>>>fields. If these numbers are in the hundreds or thousands, then you have
>>>a lossy network or NICs and need to fix that.
>>>
>>>Regardless, in recent experiments that we have run on Spread using
>>>Windows in small configurations we couldn't do much better than 40Mb
>>>(5MB) / sec. We believe that Spread's event system on Windows' doesn't
>>>perform as well as it does on *nix. We were trying to fix this before
>>>other work intervened.
>>>
>>>--
>>>John Lane Schultz
>>>Spread Concepts LLC
>>>Phn: 443 838 2200
>>>
>>>
>>>
>>>_______________________________________________
>>>Spread-users mailing list
>>>Spread-users at lists.spread.org
>>>http://lists.spread.org/mailman/listinfo/spread-users
>>
>>
>>_________________________________________________________________
>>
>>>From must-see cities to the best beaches, plan a getaway with the Spring
>>
>>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
_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee®
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
More information about the Spread-users
mailing list