1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
//$Id$
=================== RT CORBA capabilities demo ===================
Table of contents
-----------------
1. Introduction
2. Conf file parameters
3. Running the example.
1. Introduction
The Real-Time CORBA specification provides a high level API for programmers
to write distributed applications in which the priority of a distributed
thread of execution is maintained across separate hosts with potentially
different operating systems. It also provides support for explicit
binding, standard sychronizers, the ability to modify transport protocol
properties and thread pools as a standard.
In this experiment we show the effect of maintaining end to end priorities.
The experiment consists of the following participants:
Job: A CORBA servant object that performs CPU intensive work. The ammount
of work depends on a load factor that is conveyed to the object per
invocation as an argument.
Periodic Task: A periodic task is a thread of execution that is associated
with a Job. A Task periodically invokes the Job after a period of time
specified by the user.
Activity: An activity is a collection of Jobs and Tasks hosted in a single
process. An activity reads a configuration file that can be used to
initialize in many ways such as a client or server.
2. Conf file parameters
--------------------
POA OPTIONS
==========
To specify POA options the format is:
-POA <name> -PriorityModel <CLIENT|SERVER> <priority> -Lanes <count> (-Lane <priority> ,<static_threads> <dynamic_threads>)* -Bands <count> (-Band <low> <high>)*
e.g.
-POA poa1 -PriorityModel CLIENT 10 -Bands 2 -Band 1 20 -Band 30 85 -Lanes 2 -Lane 10 1 0 -Lane 80 1 0
specifes a POA with:
Name - poa1
Priority model - client propogated, def. priority = 10
Bands - 2 Bands with Band values as follows -
Band 1 : low priority = 1, high priority = 20
Band 2 : low priority = 30, high priority = 85
Lanes - 2 Lanes with Lane values as follows -
Lane 1 : priority = 10, 1 static thread, 0 dynamic threads
Lane 2 : priority = 80, 1 static thread, 0 dynamic threads
You can specify options for creating POA, Job and Task as shown
below. Please note that you must specify the number of POA, Job or Task via
the following options at the beginning of the conf. file:
-POACount [count]
-TaskCount [count]
-JobCount [count]
Job Options
===========
The format for specify a Job is:
-Job <name> <poa_name>
where, poa_name is the POA that this object is activated in.
e.g.
-Job job_10 poa1
specifies a Job with,
Name - job_10
POA Name - poa1
Task Options
============
The format for specify a Task is:
-ThreadTask -JobName <name> -Priority <priority> -Period <period> -ExecTime <exec_time> -Phase <phase> -Iter <iterations> -Load <load_weight>
where,
-ThreadTask = Specifies a Thread based timer.
-JobName <name> = Name of the Job object that this task will exec. once every period.
-Priority <priority> = The OS thread priority at which to run this task.
-Period <period> = The period of execution. (in uS)
-ExecTime <exec_time> = The offline estimate of the worst case execution time for the Job. (uS)
-Phase <phase> = The phase to start at (uS)
-Iter <iterations> = Number of Periods to exec.
-Load <load_weight> = a load factor passed to the job that varies its processing.
e.g.
-ThreadTask -JobName job_10 -Priority 10 -Period 1 -ExecTime 10000 -Phase 0 -Iter 20 -Load 1000
specifes a Thread Task in which,
JobName = job_10
-Priority = 10
-Period = 1uS
-ExecTime = 10000uS
-Phase = 0uS
-Iter = 20 iterations
-Load = 1000
4. Command-Line Options
----------------------
-Started_Flag <file_name> : When a particular activity instance has
finished bootstrapping, it will create a file specified by <file_name>
to signal that it has started. This allows scripts to synchronize when
other instances of activity can be started.
4. Running the example
----------------------
a). The activated Jobs are registered with a Naming service, so we need an NS running
e.g. ./Naming_Service -o naming_ior
b). Start one or more instances of ./activity depending on the test configuration that you have designed.
e.g. ./activity -ORBInitRef NameService=file://naming_ior -ORBSvcConf svc.conf.whatever -ORBDebugLevel 1
c) once all the instances exit, the test will generate data files: <job_name>.dat
use gen_graph to generate a .png file to view the results in a graphical viewer.
|
