The evaluation copy of the DeSiDeRaTa software (see Figure 2) consists
of the following components:
The evaluation copy of the middleware has been developed on the distributed
testbed shown in Figure 3. An example mapping of the middleware to the
hardware is shown in Figure 4. The DynBench benchmark has been used to
test the middleware. A mapping of a portion of the benchmark applications
is shown in Figure 5. The use of the middleware for benchmark startup,
dynamic QoS and resource management, and survivability management is shown
in Figures 6, 7 and 8, respectively.
The names of the directories have been defined to be self-explanatory.
The directories of greatest importance are desiderata/bin, desiderata/specfiles,
and desiderata/docs. The executables of the DeSiDeRaTa middleware
are contained in the 'bin' directory. Following installation, the spec-files
in the specfiles directory must be changed to reflect
the configuration of the distributed hardware which is to
be managed by the resource manager (for information on how to do this,
refer to the manual for D-Spec, DeSiDeRaTa?s specification language.).
The setup program will also create a folder on your desktop containing
shortcuts to all of the programs.
-
Readme
files
-
Name
Server
NAME
NS - Name Server
SYNOPSIS
NS <port>
DESCIPTION
The Name Server records the host name on which each program is running.
Additionally, it keeps track of the communication ports used by each program.
When programs initialize, they register with the name server, and when
they establish communications with other programs, they first determine
the locations and port numbers of those programs by consulting the name
server.
PARAMETERS
<port> - the port on which the name server listens.
-
Program Control
NAME
PC - program control
SYNOPSIS
PC [unique-name] [resource-mgr name]
[name server host] [name server port]
DESCRIPTION
When resource manager needs to start/stop a program on a particular
host, it informs program control, which requests the startup daemon on
that host to start (or stop) the program. When a program terminates abnormally,
program control is notified by the startup daemon which started the program;
subsequently, program control notifies resource manager.
OPERANDS
[unique-name] is the name that will identify PC.
[resource-mgr name] the name of the resource manager.
[name server host] the host on which the name server is running.
[name server port] The port number on which name server is listening.
-
Startup
Daemon
NAME
SD - Starup Daemon
SYNOPSIS
SD [program control] [name-server host]
[name-server port]
DESCRIPTION
Start and stop application programs under direction of program control.
There is one startup daemon on each host.
OPERANDS
[program control] the name of the program control application.
[name-server host] the host were the name server is running.
[name-server port] the port were the name server is listening.
-
System
Broker
NAME
SB - System Broker
SYNOPSIS
SB <unique-name> <name-server-host> <name-server-port>
DESCRIPTION
A server that provides to clients information from the system specification.
OPERANDS
unique-name : Unique name given to the System Broker
that will be used by the clients to connect to it (e.g., SB).
name-server-host : The host name of the name server host.
name-server-port : The port that binds the name server service.
-
Hardware
Monitor
NAME
HM - Hardware Monitor
SYNOPSIS
Run program. Select ?hostmon? from the System menu. Enter the following
parameters <name_server_host> <name_server_port>
<Hostbroker_name> <reporting interval>
DESCRIPTION
A daemon that resides on each host. Periodically gathers elementary
load metrics for hosts and LANS, and passes this information to the Hardware
Broker. Metrics gathered include: CPU queue length, free memory, context
switches, CPU idle percentage, Unix load average, communication in, and
communication out.
OPERANDS
reporting_interval: The report interval time, in seconds.
server_name: The name of Hardware Broker (the server to which
data is periodically sent).
name_server_host: The host name of the name server host
name_server_port: The port that binds to name server service
-
Hardware
Broker
NAME
HB - Hardware Broker
SYNOPSIS
HB <unique-name> <reporting-interval>
<name-server-host> <name-server-port>
DESCRIPTION
Collects elementary load metrics from hardware monitors, and uses these
to calculate an (aggregate) load index for each host. Periodically sends
the host load indexes to the hardware analyzer.
OPERANDS
unique-name: The unique name of Hardware Broker
reporting_interval: The periodic report interval, in seconds
name_server_host: The host name of the name server host
name_server_port: The port that binds to name server service
-
Hardware
Analyzer
NAME
HA - Hardware Analyzer
SYNOPSIS
HA <name_server_host> <name_server_port>
<resource-manager> <hardware-broker>
[-log]
DESCRIPTION
Provides a sorted list of host load indexes in response to client requests.
OPERANDS
name_server_host: The host name of the name server host
name_server_port: The port that binds to name server service
resource-manager: The unique name of resource manager
hardware-broker: The unique name of hardware-broker
OPTIONS
-log: Log all messages and actions to analyzer.dat for debug
purposes.
-
Resource
Manager
NAME
RM - Resource Manager
SYNOPSIS
RM <unique-name> <Name-server-host>
<name-server-port> <algorithm choice>
DESCRIPTION
It is activated when programs die and when time-constrained control
paths are missing their deadlines. In response to these events, it determines
how to reallocate hardware resources to improve the real-time and survivability
qualities of service.
OPERANDS
unique-name : A unique name give to the resource manager that will be
used by all the clients to connect to it (e.g., RM).
name_server_host: The host name of the name server host
name_server_port: The port that binds to name server service
algorithm choice: There are various algorithms implemented in RM.
7 must be selected. This is a facility for
allowing a choice of diagnosis algorithms.
Only one algorithm is provided in the evaluation copy.
-
QoS Manager
NAME
QM - QoS Manager
SYNOPSIS
QM QM running_mode RM SB nameserver-hostname
nameserver-port# pathID forecasting_flag
connection_to_RM
DESCRIPTION
Detects if a real-time application path becomes unhealthy (misses its
deadline), diagnoses the cause of poor health, and suggests corrective
action (such as moving or replicating an application program) to the resource
manager.
OPERANDS
QM - The unique name of the QoS Manager.
running_mode - The running mode is set to P for profiling and is set
to N for no
profiling. In profiling mode, QM does not report to RM and a log file
regarding path performance is generated. This can be used to profile applications
usage.
RM - The unique name of the Resource Manager.
SB - The unique name of the System Broker.
nameserver-hostname - The name of the host on which the name server
is
running.
nameserver-port# - The port on which the name server is listening, e.g.,
7300.
pathID - The fully qualified identifier of the path that the QoS Manager
is to
monitor,e.g., D:B:Sensing.
forecasting_flag - There are two options of this flag; use ?F? for forecasting
to be performed; use ?N? for forecasting not to be performed.
Connection_to_RM - Y or N. By default it is set to Y ( QM connects to
RM )
EXAMPLES
1. The following is an example using QM to monitor a sensing path (D:B:Sensing),
no profiling, with the name server running on nujersy, port 7300.
example% QM N RM SB nujersy 7300 D:B:Sensing
-
QoS
Manager HCI
NAME
HCI - Human Computer Interface
DESCRIPTION
HCI runs on a Windows NT machine. It establishes communication
connections (as a server) with Resource Manager, QoS Managers, and System
Broker. It displays data pertaining to host-program allocation, dynamic
real-time path structure and QoS (required and actual), and host load information.
It also allows control over the benchmark applications---they can be terminated
individually through the HCI "host" window.
TO USE
Instructions for starting and using the QoS Manager HCI are contained
in the following pages.
NOTE: Before starting the HCI, make sure you have registered
the dGraph.ocx with Windows NT. (The installation program will register
this OCX file for you, but if you change its path/directory later, you
need to re-register it by yourself.) Use the "regsvr32 dGraph.ocx"
command in the appropriate directory to do this, and you only need to register
once.
Step 1:
Start the HCI program (via the windows run menu, or by double-clicking
the HCI icon).
Select File|Connect menu (see Figure 9).
Step 2:
Input name server's host name and port number and connect to System
Broker. After connecting successfully, you can see menu items in the pull-dpwn
menus for Subsystems, Paths and Networks.
Step 3:
Select Hosts|Host View menu to invoke Host View window. Then
you can view all available hosts defined in the networks. And you can see
"hci connected" message in RM?s Xterm console.
Step 4:
Select StartSystems|[SystemName] menu to start a system. Then
you will see RM start all applications of that system .
Step 5:
Select Path|[PathName] menu to invoke path window. Then you will
see all applications of the sample path.
Step 6:
To view dynamic plotting of path-level real-time QoS, in the Path window,
press the right mouse button to invoke the context menu; select Plot
Dynamic Data.
Step 7:
To view text messages pertaining to resource management (RM) decision-making,
select the Console|RM Events menu option.
The window below shows the result of the previous steps. It also shows
how to kill a benchmark application program. A kill is done by selecting
a program in the host view window, clicking the right mouse button to invoke
the context menu, and selecting Kill from the menu.
-
Appendix:
The Dynamic Real-time Path Paradigm
This section presents the dynamic real-time path paradigm.
A path-based real-time subsystem (see Figure 16) typically consists of
a situation assessment path, an action initiation path and an action guidance
path. The paths interact with the environment via evaluating streams of
data from sensors, and by causing actuators to respond (in a timely manner)
to events detected during evaluation of sensor data streams. The system
operates in an environment that is either deterministic, stochastic or
dynamic. A deterministic environment exhibits behavior that can be characterized
by a constant value. A stochastic environment behaves in a manner that
can be characterized by a statistical distribution. A dynamic environment
(e.g., a war-fighting environment) depends on conditions which cannot be
known in advance.
A (partial) air defense subsystem can be modeled using three dynamic
paths: threat detection, engagement, and missile guidance.
The threat detection path examines radar sensor data (radar
tracks) and detects potential threats. The path consists of a radar sensor,
a sensor data stream, a filtering program and an evaluation program. When
a threat is detected and confirmed, the engagement path is activated,
resulting in the firing of a missile to engage the threat. After a missile
is in flight, the missile guidance path uses sensor data to track
the threat, and issues guidance commands to the missile. The missile
guidance path involves sensor hardware, software for filtering, software
for evaluating & deciding, software for acting, and actuator hardware.
The remainder of this section describes the features of dynamic real-time
paths. Recall that a path may be one of three types: situation assessment,
action initiation, or action guidance. The first path type, situation assessment,
continuously evaluates the elements of a sensor data stream to determine
if environmental conditions are such that an action should be taken (if
so, the action initiation path is notified). Thus, this type of path is
called continuous. Typically, there is a timeliness objective associated
with completion of one review cycle of a continuous path, i.e., on the
time to review all of the elements of one instance of a data stream. (Note:
A data stream is produced by sampling the environment. One set of samples
is called a data stream instance.)
The threat detection path of the air defense system is an example
of a continuous path. It is a sensor-data-stream-driven path, with desired
end-to-end cycle latencies for evaluation of radar track data. If it fails
to meet the desired timeliness Quality of Service in a particular cycle,
the path must continue to process track data, even though desired end-to-end
latencies cannot be achieved. Peak loads cannot be known in advance for
the threat detection path, since the maximum number of radar tracks
can never be known. Furthermore, average loading of the path is a meaningless
notion, since the variability in the sensor data stream size is very large
(it may consist of zero tracks, or it may consist of thousands of tracks).
The second path type, action initiation, is driven by a stream of events
sent by a continuous (situation assessment) path. It uses inputs from sensors
to determine which actions should be taken and how the actions should be
performed, notifies actuators to start performing the actions, and informs
the action guidance path that an action has been initiated. We call this
type of path transient, since it performs work in response to events.
Typically, a timing objective is associated with the completion of the
initiation sequence. The importance of the timing objective for a transient
path is often very high, since performance of an action may be mission-critical
or safety-critical.
For example, the engagement path of the air defense example is
a transient path. It is activated by an event from the threat detection
path, and has a QoS objective of end-to-end timeliness. The real-time
QoS of this path has a higher priority than the real-time QoS of the continuous
threat detection path.
The third path type, action guidance, is activated by an action initiation
event, and is deactivated upon completion of the action. Action guidance
repeatedly uses sensor inputs to monitor the progress of an actuator, to
plan corrective actions needed to guide the actuator to its goal, and to
issue commands to the actuator. This type of path is called quasi-continuous,
since it behaves like a continuous path when it is active. A quasi-continuous
path has two timeliness objectives: (1) cycle completion time: the
duration of one iteration of the "monitor, plan, command" loop, and (2)
action completion time (or deactivation time): the time by which the action
must complete in order for success. Note that it is more critical to perform
the required processing before the action completion deadline than it is
to meet the completion time requirement for every cycle (although the two
deadlines are certainly related). Thus, it is acceptable for the completion
times of some cycles to violate the cycle deadline requirement, as long
as the desired actions are successfully completed by the deactivation deadline.
The missile guidance path of the air defense example is
a quasi-continuous path. It is activated by the missile launch event.
Once activated, the path continuously issues guidance commands to the missile
until it detonates (the deactivation event). The required completion time
for one iteration is dynamically determined, based on characteristics of
the threat. If multiple threat engagements are active simultaneously, the
threat engagement path is responsible for issuing guidance commands to
all missiles that have been launched.
-
Desiderata
(a poem)
Go placidly amid the noise and the haste
and remember what peace there may be in silence.
As far as possible without surrender,
be on good terms with all persons.
Speak your truth quietly and clearly
and listen to others, even to the dull and ignorant.
They too have their story.
Avoid loud and aggressive persons,
they are vexations to the spirit.
If you compare yourself with others
you may become vain or bitter,
for always there will be greater
and lesser persons than yourself.
Enjoy your achievements as well as your plans.
Keep interested in your own career, however humble,
it is a real possession in the changing fortunes of time.
Exercise caution in your business affairs,
for the world is full of trickery.
But let this not blind you to what virtue there is.
Many persons strive for high ideals,
and everywhere life is full of heroism.
Be yourself.
Especially do not feign affection
neither be cynical about love,
for in the face of all aridity and disenchantment
it is as perennial as the grass.
Take kindly the counsel of the years,
gracefully surrendering the things of youth.
Nurture strength of spirit to shield you in sudden misfortune
but do not distress yourself with dark imaginings.
Many fears are born of fatigue and loneliness.
Beyond a wholesome discipline, be gentile with yourself.
You are a child of the universe
no less than the trees and the stars;
you have a right to be here.
And whether or not it is clear to you,
no doubt the universe is unfolding as it should.
Therefore be at peace with God,
whatever you conceive him to be,
and whatever your labors and aspirations,
in the noise and confusion of life,
keep peace in your soul.
With all its sham, drudgery and broken dreams,
it is still a beautiful world.
Be cheerful,
Strive to be happy.
["Desiderata" was written in 1927 by Max Ehrmann (1872-1945).]
-
Computing
Desiderata (another poem)
Go placidly amid the hardware faults and the QoS
violations
and remember what peace there may be in silence.
As far as possible without surrender,
be on good terms with all users .
Speak your resource management policies quietly and clearly
and listen to others, even to the dull and ignorant.
They too have their policies.
Avoid malicious and aggressive programs,
they are vexations to the system .
If you compare yourself with others
you may become vain or bitter,
for always there will be greater
and lesser algorithms than yours.
Enjoy your achievements as well as your plans.
Keep interested in your own computer, however humble,
it is a real possession in the changing fortunes of time.
Exercise caution in your network transactions,
for the internet is full of trickery.
But let this not blind you to what virtue there is.
Many persons strive for high ideals,
and everywhere life is full of heroism.
Be yourself.
Especially do not feign affection
neither be cynical about love,
for in the face of all aridity and disenchantment
it is as perennial as the grass.
Take kindly the counsel of the Microsoft,
gracefully surrendering the things of Unix.
Nurture redundancy of resources to shield you in sudden
misfortune
but do not distress yourself with dark imaginings.
Many fears are born of over-utilization and idleness.
Beyond a wholesome discipline, be gentile with your applications.
You are a child of the information age
no less than the microwaves and the palm pilots;
you have a right to be here.
And whether or not it is clear to you,
no doubt the age is unfolding as it should.
Therefore be at peace with your computing paradigm,
whatever you conceive it to be,
and whatever your requirements and objectives,
in the noise and confusion of dynamic computing environments,
maximize QoS in your system.
With all its unpredictability, faults and violated QoS
requirements,
it is still a beautiful domain.
Be optimal,
Strive to have happy applications and users.
