#######################################

# General information

#######################################

[RCF]

version 0.1

nick Events Generator (one node)

created Wed May 16 13:44:11 EDT 2007

modified Wed May 16 13:47:51 EDT 2007

authors anna



[System]

# Number of machines used to simulate radar 
nodes
num_sensor_nodes 1

# Number of machines used to emulate the SOCC

nodes_in_SOCC 1



#######################################
# 
# Rules for forming different types of messages.

# Syntax:

# <message_type> <start_event> <end_event> <color>

#

# A message of the <message_type> is formed by the <start_event> and 

# <end_event>. On the rapids message diagram messages of this type 

# will be displayed using the color <color>.

#

# Important!

# The actual mechanism that uses this input to form messages

# has not been implemented yet.

#######################################

[Messages]

LDM LDM.PQ_INSERT LDM.PQ_REMOVE java.awt.Color[r=205,g=38,b=38]

WDSS WDSS.LB_INSERT WDSS.LB_REMOVE java.awt.Color[r=0,g=205,b=102]



#######################################

# Configuration file for the radar data generator.

# Supposed to be used for generating netcdf files on the fly.

#######################################

[RDG]
rdg_conf -



#######################################

# The following sections describe setups of the machines

# involved in the emulation: IP addresses of the machines, processes 

# that will be started on them, metrics to be collected etc.

# 

# The order in which the setups are listed determines where the corresponding

# machines will appear in the rapids message diagram. SOCC machines always

# will appear at the bottom of the diagram, while radar nodes will appear at 

# the top. Also, the first machine listed in the SOCC group will appear at the

# lowest line on the diagram, the second listed machine will be displayed 

# above the first one and so on.

#

# The same order of appearance applies for the radar nodes.

#

# If there is more than one machine in the SOCC, their setups should 

# be described in sections [SOCC 1.2], [SOCC 1.3] and so on.

# If there is more than one radar node, their setups should

# be described in sections [Sensor 2], [Sensor 3] and so on.

#######################################

[SOCC 1.1]

# Nick name as it will appear on the message diagram

name Mr. Norrel

ip_address emmy1.casa.umass.edu/128.119.245.35



# Rules that specify how to start processes on this machine
# Syntax:

# <rapids_exec | rapids_shut> <C | S> <command>

#

# rapids_exec means that the <command> will be executed at the

#             beginning of the emulation

# rapids_shut means that the <command> will be executed at the

#             end of the emulation

# C           the <command> will be executed

# S           means that <command> is a script. This script will be

#             transferred to this machine and executed there.


rapids_exec  C /nfs/erc/users2/abekkerm/Emulator/EventsGenerator/generator

#rapids_exec  S /nfs/erc/users2/abekkerm/scripts/start_generator



rapids_shut  C perl /usr/share/rapids/utils/bin/killer.pl generator



# Rules that specify which system metrics will be collected

# Syntax:

# rapids sysevent metric <key> <significant_change>

#

# Existing keys:

# 1	CPU utilization

# 2	Workload: the number of  jobs  in  the  run queue (state R) 

#	or waiting for disk I/O (state D) averaged over 1, 5, and 

#	15 minutes

# 3	Memory utilization (RAM and swap space)

#

# 

rapids sysevent  metric 1 1.0

rapids sysevent  metric 2 1.0

rapids sysevent  metric 3 1.0




# Rules describing monitored processes and metrics that will be 
# collected for them. The rules that start with the 'display'
# keyword describe how processes will be displayed on the Message
# diagram. 
#
# Each process P is assigned a line on the diagram. All events generated
# by P are displayed on this line. Also, P has a color code used to depict
# events of P. 
#
# Several processes might be assigned the same line. These processes
# will have the same group ID. If a group ID of a
# process is 0, it means that this process has it's own line.
#
# The process's name is either it's filename as it appears in 
# /proc/[pid]/stat or it's nickname as specified by a user through
# the Rapids API call.
#
# Syntax:
# display procgroup <process_name> <group_id>
# display proccolor <process_name> java.awt.Color[<color_code>]

display procgroup generator 0

display proccolor generator java.awt.Color[r=198,g=118,b=175]

display procgroup other_proc1 1

display proccolor other_proc1 java.awt.Color[r=118,g=149,b=183]

display procgroup other_proc2 1

display proccolor other_proc2 java.awt.Color[r=115,g=165,b=5]



# Rules that specify which process metrics will be collected

# Syntax:

# rapids procevent <process_name> metric <key> <significant_change>

#

# Existing keys:

# 100	CPU utilization

# 101	Process state: running, sleeping etc
# 102	Start time
# 103	PID
# 104	Parent ID
#
# If a process is not specified among displayed processes,
# it will not appear on the Message diagram but in the "Process
# Metrics" display only.
#
# There are rules that specify which events will be displayed
# on the diagram for a certain process:
# Syntax:
# rapids procevent <process_name> message <event_type>
#
# Important!
# This filtering feature has not been implemented yet.

rapids procevent generator metric 100 1.0

rapids procevent generator metric 101 -

rapids procevent generator metric 102 -

#rapids procevent generator metric 103 -

#rapids procevent generator metric 104 -

rapids procevent generator message WDSS

rapids procevent generator message LDM

rapids procevent other_proc1 metric 100 5.0

rapids procevent other_proc1 metric 101 -

rapids procevent other_proc1 metric 102 -

#rapids procevent other_proc1 metric 103 -

#rapids procevent other_proc1 metric 104 -

rapids procevent top metric 102 -


# A rule that specify the update rate: how frequently new data
# is collected
# Syntax:
# rapids update <update_rate_in_sec>
rapids update 5



[Sensor 1]

name Jonathan Strange

ip_address emmy2.casa.umass.edu/128.119.245.36





rapids update 5



# A rule that set up parameters for simulation of network delays
# and/or drop rates on a link between the SOCC and this sensor node.
# Each packet will be delayed for a time period: 'delay'+- delta, where
# delta is chosen randomly between 0 and 'delay_variance'. Also, 'drop_rate'
# percent of all packages will be dropped.
#
# Syntax:
# network_delay <delay> <delay_variance> <drop_rate>

network_delay 20 30 40