PEPP: Performance Evaluation of Parallel Programs

PEPP: Performance Evaluation of Parallel Programs
PEPP: Performance Evaluation of
Parallel Programs
User's Guide { Version 3.3
P. Dauphin, F. Hartleb, M. Kienow,
V. Mertsiotakis, A. Quick
Erlangen, September 1993
Technical Report 17/93
PEPP: Performance Evaluation
of Parallel Programs
User's Guide | Version 3.3
P. Dauphin, F. Hartleb, M. Kienow,
V. Mertsiotakis, A. Quick
IMMD VII
University of Erlangen{Nurnberg
Martensstr. 3, D{91058 Erlangen, Germany
Tel.: 09131/857411, Fax: 09131/85-7409
e{mail: pdauphin@immd7.informatik.uni-erlangen.de
quick@immd7.informatik.uni-erlangen.de
vsmertsi@immd7.informatik.uni-erlangen.de
Technical Report 17/93
Erlangen, September 1993
History of PEPP
The rst version of PEPP (Version 1.0) was implemented in 1990. Its intention was to
build an X-window based interface to ease the input and generation of stochastic graph
models for performance evaluation. As evaluation method the approximate state space
analysis was implemented. In this version, PEPP supported elementary nodes, parallel
nodes, and loop nodes. The rst step concerning the methodology of integrating modeling
with monitoring was done by implementing the automatic generation of instrumentation
command les for the instrumentation tool AICOS, developed at the same time.
Version 2.0 has been released in September 1991 when the integration of the already
existing series-parallel structures solver SPASS was nished. For model evaluation the
bounds of Kleinoder, Dodin, Shogan, and Devroye were implemented to enable evaluation
of larger models by PEPP. Furthermore, the set of available node types was extended
by hierarchical nodes. The tool CAPP was implemented for graphical presentation of
numerical densities and evaluation results.
As the emphasis of the rst two versions laid in model evaluation, Version 3.0 (April
1992) is characterized by large extensions concerning the integration of modeling and monitoring. Thus, the concept of event trace validation was realized as well as the automatic
generation of input les for the animation tool VISIMON. Besides, the set of available
node types was extended by hierarchical loop nodes. The exibility of the instrumentation
tool AICOS was improved.
Since Version 3.1 in September 1992, PEPP supports the assignment of dierent monitoring statements to dierent instrumentation points for each node. Therefore, generic
trace-functions for instrumentation with AICOS were necessary and realized. Besides, the
creation of descriptor les for the SIMPLE tools gantt and trcstat was now possible.
In Version 3.2 (December 1992) the creation of ZM4 conguration les has been realized
to support the carrying-out of measurements done by the hardware monitor ZM4.
Since Version 3.3 (July 1993) it is possible to carry out validation and event trace analysis
using SIMPLE simultaneously in a synchronous mode in order to improve the detection
of performance errors.
3
Contents
1 Introduction
1
2 PEPP | an Overview
5
2.1 Invocation of PEPP : : : : : : : : : : : : : : : : : : : :
2.2 The Main Menu : : : : : : : : : : : : : : : : : : : : : :
2.2.1 Administrative Functions : : : : : : : : : : : : :
2.2.1.1 Model: Model Handling : : : : : : : :
2.2.1.2 Canvas Setup: Canvas Conguration
2.2.1.3 Undo: Undo Last Modication : : : :
2.2.1.4 Manual: The PEPP Online Manual : :
2.2.2 Operational Functions : : : : : : : : : : : : : :
2.3 Quit PEPP : : : : : : : : : : : : : : : : : : : : : : : :
3 Model Creation
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
3.1 The Canvas Menu : : : : : : : : : : : : : : : : : : : : : : : :
3.1.1 Create: Create Nodes and Edges : : : : : : : : : : :
3.1.1.1 Create Nodes : : : : : : : : : : : : : : : : :
3.1.1.2 Create Edges : : : : : : : : : : : : : : : : :
3.1.1.3 The Help Function : : : : : : : : : : : : : :
3.1.2 Change: Change Node Parameters : : : : : : : : : :
3.1.3 Delete: Delete Nodes and Edges : : : : : : : : : : :
3.1.4 Copy: Copy Nodes : : : : : : : : : : : : : : : : : : :
3.1.5 Copy Into: Copy Node Parameters : : : : : : : : : :
3.1.6 Edge Probability: Create Branching Edges : : : :
3.1.7 Mapping: Assign Processor/Process Names to Nodes
i
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
5
7
8
8
9
9
10
10
11
13
13
13
13
19
19
20
20
20
21
22
23
3.1.8
Show Density:
Graphical Display of Numerical Densities : : : : : : 24
3.2 Functions in the Drawing Canvas : : : : : : : : : : : : : : : : : : : : : : : 24
3.2.1 Enter and Exit a Subgraph : : : : : : : : : : : : : : : : : : : : : : : 24
3.2.2 Move Nodes : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 25
3.2.3 Select Edge Type and Redraw Canvas : : : : : : : : : : : : : : : : 25
3.2.4 Display Node Parameters : : : : : : : : : : : : : : : : : : : : : : : 26
4 Program Instrumentation
27
Dene Instrumentation Points : : : : : : : : : : : : : : : : : 27
4.1
Instrument:
4.2
Instrumentation:
Create an Instrumentation Command File : : : : : : : 29
4.3 Automatic Instrumentation with AICOS : : : : : : : : : : : : : : : : : : : 30
4.3.1 Invocation of AICOS : : : : : : : : : : : : : : : : : : : : : : : : : : 31
4.3.2 The AICOS Command File Language : : : : : : : : : : : : : : : : : 34
5 Create ZM4 Conguration Files
39
5.1 Architecture of the Hardware Monitor ZM4 : : : : : : : : : : : : : : : : : 39
5.2
Monitor:
Create ZM4 Conguration Files : : : : : : : : : : : : : : : : : : 40
6 Consistency Validation
6.1
Validation:
43
Start Validation : : : : : : : : : : : : : : : : : : : : : : : : : 43
6.2 Synchronizing Validation and Trace Analysis : : : : : : : : : : : : : : : : : 45
6.3 Results of Validation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 47
7 Trace Analysis
7.1
Statistic:
7.2
Gantt:
7.3
Visimon:
51
Create a Description File for trcstat : : : : : : : : : : : : : : 51
Create a Description File for gantt : : : : : : : : : : : : : : : : : : 53
Create an Animation Description File : : : : : : : : : : : : : : : 54
7.3.1 Invocation of VISIMON : : : : : : : : : : : : : : : : : : : : : : : : 57
7.4
Filter:
Create a Description File for fdlc : : : : : : : : : : : : : : : : : : 58
ii
8 Model Evaluation
8.1 Available Evaluation Methods in PEPP : : : : : : : : : : : : : : : : : : : :
8.1.1 State Space Analysis : : : : : : : : : : : : : : : : : : : : : : : : : :
8.1.2 SPASS Analysis : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
8.1.3 Bounding Methods : : : : : : : : : : : : : : : : : : : : : : : : : : :
8.2 Graphical Presentation of Results using CAPP : : : : : : : : : : : : : : : :
8.2.1 Invocation of CAPP : : : : : : : : : : : : : : : : : : : : : : : : : :
8.2.2 Properties of CAPP : : : : : : : : : : : : : : : : : : : : : : : : : :
8.2.3 Usage of CAPP : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
8.2.3.1 Distribution: Create the Numerical Representation of a
Distribution : : : : : : : : : : : : : : : : : : : : : : : : : :
8.2.3.2 Load, Save: Load and Save a Numerical Representation :
8.2.3.3 F(t): Display Distribution Function : : : : : : : : : : : :
8.2.3.4 Combination of two Numerical Representations : : : : : :
8.2.3.5 Print: Print a Distribution/Density : : : : : : : : : : : :
8.2.3.6 Quantil: Computation of Quantiles and Distribution
Function{Values : : : : : : : : : : : : : : : : : : : : : : :
8.2.3.7 Moments: Computation of Higher Moments : : : : : : : :
8.2.3.8 Canvas Setup: Change of Scale : : : : : : : : : : : : : :
8.2.3.9 Quit: Leave the Program CAPP : : : : : : : : : : : : : :
59
59
60
61
62
63
63
64
64
65
65
66
66
66
67
67
67
67
9 Customizing PEPP
69
References
70
iii
1 Introduction
PEPP (Performance Evaluation of Parallel Programs) is a modeling tool for creating
and evaluating stochastic graph models of parallel and distributed programs. PEPP oers
functions for graphical model creation and various evaluation methods for calculating the
mean runtime of a program. Besides, PEPP can be used for event{driven monitoring, as
our idea of performance evaluation, tuning, and debugging is to integrate modeling and
monitoring to a comprehensive methodology ([DHK+92]).
In using event{based models which explicitly model the functional interdependence of
activities, and event{driven monitoring, there is a common abstraction | the event |
which enables us to integrate both methods. Both in modeling and monitoring, important
points are represented as events of interest and the overall dynamic behavior as an event
trace. Due to this very close connection between the ow description in modeling and
monitoring it is desirable to use the same set of events for modeling and monitoring. This
integration has advantages in two ways:
performance prediction can be carried out with realistic parameters. Using parameters obtained from monitoring, performance prediction becomes more relevant.
event specication for monitoring can be carried out in a systematic way. This is a
great help, as monitoring distributed and parallel systems is a hard task.
The integration of modeling and monitoring is called model{driven monitoring. The model
on which the instrumentation is based is called monitoring model. The basis of model{
driven monitoring is model{driven instrumentation. Dening events for monitoring is based on the monitoring model. All activities represented in the monitoring model will
be instrumented in the corresponding program at their entry and all exit points. The
dicult questions \What should be measured?" and \Where should the program be instrumented?" are implicitly answered by building the monitoring model. Model{driven
instrumentation versus intuitive instrumentation oers a lot of advantages.
In g. 1.1 the use of PEPP and AICOS for model{driven monitoring is shown. In this
gure a number in the upper left corner of a rectangle indicates the chapter of this manual
where this tool or this feature of PEPP is explained. The ve rectangles in the box PEPP
represent the main features of PEPP corresponding to the buttons in the main menu of
PEPP. This gure can serve as an overview for the whole manual; it will not be explained
in detail in the introduction.
The following features of model{driven monitoring are supported by PEPP (cf. g. 1.1):
Creation: The rst step is to create a model. For model{driven monitoring this
graph model serves as a monitoring model. This model can be created interactively
with graphical support.
1
CHAPTER 1. INTRODUCTION
2
2
PEPP
3
Creation
program
monitoring
model
4
Instrumentation
Automatic
Instrumentation
with AICOS
AICOS
command file
5
Monitor
instrumented
program
ZM4
configuration file
trace descript.
in TDL
Monitoring
with ZM4
TDL-Compiler
key file
6
7
Validation
event trace
Trace Analysis
Trace Analysis
with SIMPLE
configuration files
for trace analysis
8
trace analysis
results
Evaluation
modeling
results
validation
results
Figure 1.1: Model{driven monitoring using PEPP, AICOS, and SIMPLE
3
Instrumentation: For automatic and systematic instrumentation a command
le for an instrumentation tool can automatically be created. There is a one{to{
one mapping between the model events and the monitoring events. All activities
represented in the model will be instrumented by an instrumentation tool. PEPP
creates a command le for the instrumentation tool AICOS. With AICOS, programs
written in the programming language C can automatically be instrumented.
Monitor: After instrumentation, the instrumented program can be executed and
monitored. This feature of PEPP supports the use of the distributed hybrid monitor
system ZM4. Conguration les for the ZM4 monitor can automatically be created.
Validation: The monitoring of an instrumented program results in an event trace.
The monitoring model can be used for validating the dynamic behavior of the program. Validation is necessary in order to draw correct conclusions. The monitored
behavior represented in the event trace can automatically be checked against the
functional behavior of the model. This kind of validation provides hints for nding
program errors. If the recorded event trace matches the monitoring model, the trace
can be used as a base for evaluation. In order to improve performance evaluation
PEPP can associate performance analysis results with specic parts in the model
and the program. Analyzing the event trace subsequently after validating the functional consistency of trace and model, the association between validation results
and performance evaluation results is missing. With PEPP validation can be synchronized with event trace analysis enabling simultanuously checking the functional
consistency between the model and the trace and to build up trace analysis results
in a stepwise manner.
Trace Analysis: Most tools of the evaluation environment SIMPLE need description les with evaluation commands. These description les can automatically
or interactively be created by PEPP using the information contained in the monitoring model. Calculating runtime distributions, creating Gantt charts, or creating
an animation description can be carried out in a model{driven way. In this version of PEPP, only the creation of an animation description for the animation tool
VISIMON is implemented yet.
Evaluation: The results of the event trace analysis can be used for creating a
performance model with realistic parameters. Runtime distributions and branching
probabilities will be assigned to the activities of the monitoring model. The performance model is a prerequisite for predicting the performance of not yet implemented
program versions, process mapping, or other computer congurations. The use of
measured parameters means model evaluation with realistic data and therefore relevant results. PEPP supports various evaluation methods such as state space analysis,
series{parallel reduction, and approximation with bounds.
4
CHAPTER 1. INTRODUCTION
2 PEPP | an Overview
The introduction emphasizes that PEPP (Performance Evaluation of Parallel Programs)
is the central tool for model{driven monitoring based on stochastic graph models. This
section deals with the invocation of PEPP and its main functions, which are subdivided into administrative and operational functions. PEPP is an X{Window application
implemented with MIT{X11R4.
2.1 Invocation of PEPP
PEPP can be invoked in the following way:
pepp [-m
model le]
[-k
key le]
trace le] [-s]
[-P property name] [X{Options]
[-t
Options:
All options dened for X{Window applications may be given (see X(1)
for details).
model le A model stored in model le is loaded when starting PEPP.
key le
A key le key le containing the description of a monitored event trace
is loaded when starting PEPP. If a trace le is not specied with the
option -t, the corresponding trace le is loaded. In this case key le
should not have the default extension .key. A keyle can be obtained
from an event trace description in TDL using the TDL{Compiler tdlc
([Moh92]).
A trace le trace le containing the monitored event trace is loaded
trace le
when starting PEPP. If a key le is not specied with the option
-k, the corresponding keyle is loaded. Therefore, it is necessary that
trace le does not have the extension .trc.
The model specied with the option -m will be evaluated with the
state space method. After the evaluation the result will be saved to
model le and PEPP nishes its execution.
property name The validation process (see section 6) can be combined with the
trace analysis process (see section 7). This allows to step through an
event trace and simultanuously carry out various performance evaluations of the given event trace using X window based tools of our event
trace evaluation environment SIMPLE [Dau93]. Pepp communicates
X{Options
-m
-k
-t
-s
-P
5
CHAPTER 2. PEPP | AN OVERVIEW
6
with the evaluation tools via the X window protocol using the available mechanism of properties appended to the X-server's root window
(for more details see section 6).
Usually pepp communicates with the evaluation tools to be controlled via a set of default properties. Using the option -P, pepp is forced
to communicate via a special set of properties. The properties' name
is built up by concatenating the default names and the name property name.
The option can be given several times which causes pepp to instantiate
several sets of properties. Note, that the total number of properties
which may be installed on an X-server is server-dependent (see manual
pages for X(1)).
A key le and a trace le are needed if the consistency between the monitoring model and
the monitored event trace should be validated (see section 6). Some of the trace analysis
functions described in section 7 do also require a key le and a trace le.
The default extensions of the input les are .mod for the model le, .key for the key le,
and .trc for the trace le.
Valid environment variables considered by PEPP are:
KEYDIR
This environment variable contains a list of directories separated by
colons (:) where key les should be looked for.
TRACEDIR This environment variable contains a list of directories separated by
colons (:) where event trace les should be looked for.
The user interface of PEPP is divided horizontally into four parts (see g. 2.1):
Main menu:
In this menu all basic functions for handling a graph model are
located.
Canvas menu:
This menu contains functions necessary for creating or modifying
a graph model. Both, simple drawing functions and functions for
adding parameters are available.
Status line:
The actual location inside the graph model is displayed here. The
name of the model and the hierarchical position in the model is
displayed.
Drawing canvas: This part of the user interface represents the visible drawing
area.
2.2. THE MAIN MENU
7
Figure 2.1: The user interface of PEPP
The functions of the main menu are described in the next section. In section 3.1 the
functions of the canvas menu are explained.
2.2 The Main Menu
The functions available in the main menu are shown in g. 2.2:
Model
Canvas Setup
Undo
Manual
Instrumentation
Monitor
Validation Trace Analysis Evaluation
Figure 2.2: The main menu
In the main menu we distinguish between administrative and operational functions. Functions can be invoked by pressing the left mouse button on the function name. With the
exception of the Undo{, and the Manual{button, a submenu or dialog window comes up
when pressing the left mouse button. These windows consist of buttons and input elds.
Functions can be invoked by pressing the left mouse button. In input elds input from the
terminal is expected. The text cursor must be moved into an input eld with the mouse.
The next elds can be entered either with the mouse, with the arrow keys " and #, or
with the Return{key. The Return{key closes the input when pressed in the last input
eld. The default exit of all dialog windows is indicated by a bold style button.
CHAPTER 2. PEPP | AN OVERVIEW
8
2.2.1 Administrative Functions
2.2.1.1
Model:
Model Handling
The function Model opens a submenu with three functions: load, save, and print. Pressing load or save a dialog window comes up where a le name for loading or saving
a model is requested. The extension .mod of the le name can be omitted. The button
cancel is used to leave the dialog window without doing anything.
With load a new model can be loaded into PEPP. Two alternatives are oered:
Load
Complete
Load
Subgraph
:
:
The model stored in the specied le is loaded as a new main
graph.
The model stored in the specied le is loaded as a new current
subgraph.
Using save the current model can be saved in the specied le. As with load, two alternatives are possible:
Save
Save
:
Subgraph:
Complete
The main graph and all subgraphs are saved in the specied le.
Only the current subgraph and its subgraphs are saved in the
specied le.
With print the current model can be stored as a PostScript le. The following parameters
have to be specied:
Print File:
Specify the le name of the PostScript le. The le extension
.ps can be omitted (default: rst part of the model name with
the extension .ps).
Title, Subtitle: Dene a title and/or a subtitle that should appear when printing
the model (optional).
Scale Paper:
Scale down the size of the model (default: 1). The scale factor
must be in (0; 1].
Print Format:
Specify output format (default: portrait).
Show Result:
If available, print evaluation results obtained from state space
analysis additionally (default: o). For the graphical presentation of evaluation results obtained from other evaluation methods see section 8.
Print Complete: Print the main graph and all subgraphs, each on its own page.
Print Subgraph: Print only the current subgraph.
If just one page is to be printed, the generated output le is in the encapsulated PostScript
format (EPSF) for further use in other PostScript les.
2.2. THE MAIN MENU
2.2.1.2
Canvas Setup:
9
Canvas Conguration
When pressing the button Canvas Setup a dialog window showing functions for canvas
conguration together with some auxiliary functions appears:
Grid
: Here the vertical and horizontal distance of grid
points can be modied. The grid points are meaningful in conjunction with the function Snap (default: 20).
Delta-X, Grid Delta-Y
Canvas width, Canvas
(default: 2000).
Grid
display
Snap
mode
: Change the size of the (virtual) drawing canvas
height
: Toggle display of grid on/o (default: o).
:
When Snap mode is on, nodes can only be positioned on grid points.
When Snap mode is o nodes may be located anywhere in the drawing
canvas (default: o).
Setup:
The specied changes of the canvas conguration are carried out. The
function Canvas Setup will be left.
Snap:
This function behaves like Setup, but additionally it positions every
existing node at the nearest grid point. The function Canvas Setup
will be left.
Survey:
The survey of the current graph or subgraph is displayed in the canvas.
You exit the survey mode by clicking the left mouse button in the
canvas. The function Canvas Setup will be left, the canvas parameters
are not changed.
Clear Complete: This function removes the main graph and all subgraphs. The function Canvas
Setup
will be left, the canvas parameters are not changed.
Clear Subgraph: Only the current subgraph is removed. If there are any hierarchical nodes in the subgraph their subgraphs will also be removed. The
function Canvas Setup will be left, the canvas parameters are not
changed.
Cancel:
2.2.1.3
Undo:
Leave the function Canvas
Setup
without changing any parameters.
Undo Last Modication
With the function Undo the last model change can be undone. Before any modication of
the model the actual model is saved in an auxiliary le. Using Undo the last modication
can be reconstructed.
CHAPTER 2. PEPP | AN OVERVIEW
10
2.2.1.4
Manual:
The PEPP Online Manual
The display of the PEPP user's guide can be invoked within PEPP by the main menu
function Manual. The text is displayed via the ghostview(1) command. Therefore, it is
necessary that the le pepp man.ps can be read in one of the following directories:
Actual working directory
Home directory
Resource directory $XAPPLRESDIR
System resources directory SYSTEMRESDIR which is dened in PEPP's Makele (normally /usr/lib/X11/app-defaults)
You can change the manual viewer and the manual le in the resource le Pepp (see
section 9).
2.2.2 Operational Functions
PEPP supports model{driven monitoring by oering the following functions:
model creation: Before starting model{driven monitoring, a model has to be crea-
ted (see section 3). For model{driven monitoring this model serves as
a monitoring model.
instrumentation: As we deal with event{driven hybrid monitoring or software monitoring events are dened by inserting so{called monitoring instructions into the program to be analyzed. This is called instrumentation.
The instrumentation using PEPP and the instrumentation tool AICOS are explained in section 4. With AICOS, programs written in
the programming language C can automatically be instrumented.
monitor:
Hybrid monitoring with the distributed hybrid monitor system ZM4
is supported with this function. Section 5 shows how to create conguration les for the ZM4 with this function.
validation: To be sure that the monitored event trace matches the behavior represented in the monitoring model, the consistency between the monitoring model and the event trace has to be validated. The consistency
validation is described in section 6.
trace analysis: With PEPP, conguration les for trace analysis with SIMPLE
tools can automatically be created. Based on the monitoring model, conguration les for calculating runtime distributions, displaying
Gantt charts for selected model activities, or for animation of the monitored behavior can be created (see section 7).
2.3. QUIT PEPP
11
evaluation: A time parameter can be assigned to each node of the model. This
parameter can be obtained from a monitored event trace. When evaluating the model, the mean runtime of the program or runtime distributions can be calculated. The evaluation part of PEPP also allows
performance prediction (see section 8).
2.3 Quit PEPP
Pressing the Quit PEPP button, the tool PEPP is left properly. If there are unsaved
changes of a model the user is asked to save the changes before leaving PEPP.
12
CHAPTER 2. PEPP | AN OVERVIEW
3 Model Creation
The basis of the model{driven monitoring is the model itself. The Program PEPP supports
the creation of a model by providing a few construction functions, which are collected in
the canvas menu. Additional functions for graph layout are supported by the drawing
canvas.
3.1 The Canvas Menu
The buttons in the canvas menu allow the selection of functions for creating or modifying
a graph model in the drawing canvas. In g. 3.1 the available functions are shown. A
function can be chosen by pressing the left mouse button on the desired button.
Create
Change
Delete
Copy
Copy Into
Edge Probability
Mapping
Instrument Show Density
Figure 3.1: The canvas menu
Once a function is selected in the canvas menu (indicated by reverse mode), the mouse
buttons have the following meaning, provided that the mouse is inside the drawing
canvas:
left:
Activate selected canvas function.
middle: Move node while keeping the button pressed (drag).
right: When pressed on a node, a window appears displaying the node's para-
meters. Otherwise a selection menu for edge style modication comes up
(see section 3.2.3).
3.1.1
Create:
Create Nodes and Edges
A stochastic graph consists of nodes and edges. The nodes represent program tasks, the
edges represent the dependencies between the tasks and their execution order. With the
function Create, both nodes and edges can be created.
3.1.1.1 Create Nodes
To create a node, the left mouse button is pressed in the drawing canvas at the position
where the node should be placed. Then a window appears where the node's parameters
can be specied (see g. 3.2).
13
CHAPTER 3. MODEL CREATION
14
CREATE NODE
Node type:
Distr. type:
Distr. params:
Loop type:
Loop params:
Node name:
Processor:
Node label:
Source le:
Create
^
^
^
^
^
^
^
^
^
Cancel
Figure 3.2: Create a new node
The following parameters are expected:
Node type
Species the type of the node, PEPP oers ve dierent types (see g. 3.3):
H
hierarchical node
L
hierarchical loop node
E
elementary node
P parallelity
parallel node (parallelity must be between 1 and 99999)
C
cyclic node
Elementary nodes (E) can be used for modeling sequential program tasks. With
parallel nodes (P), activities running in parallel can be modeled. Hierarchical nodes
are needed to indicate an embedded subgraph. For hierarchical nodes, only the parameters Node name and Node label are taken into account. All other parameters
are ignored.
Cyclic nodes (C) are needed to model the execution of a loop. The whole loop is
considered as one block. The runtime distribution of the loop body (one loop cycle),
the branching type, and the branching parameters must be given.
3.1. THE CANVAS MENU
15
elementary node
E
=
F(t)
cyclic node
C
parallel node
=
P
F(t)
F(t)
F(t)
hierarchical node
F(t) p
1-p
hierarchical loop node
= PEPP-graph
L
=
H
=
PEPP-graph
p
1-p
Figure 3.3: Dierent node types in PEPP
Hierarchical loop nodes (L) can be used to model the execution of a loop and the
loop body in more detail than with cyclic nodes. The body of the loop is modeled as
a subgraph similar to hierarchical nodes (H). For hierarchical loop nodes the parameters Node name, Node label, and Loop type are needed. For validation reasons,
only loop type u (uniform) is allowed (see explanations for Loop type).
Distr. type
Distr. params
Species the type of runtime distribution of the node. PEPP distinguishes ve distribution types:
d deterministic distribution
e exponential distribution
a approximative distribution
b mixed Erlang distribution (branching Erlang)
n numerical distribution generated by the program CAPP (see section 8.2)
Species the parameters of the selected runtime distribution (see parameter
):
Distr. type
CHAPTER 3. MODEL CREATION
16
Distr. type
Parameters
d
e
e
a
ev
b
p1 k1 1 : : :pn kn n
Range
e0
>0
e 0; v 0
1n9
0 pi 1; i > 0;
ki P0; ki integer,
n p =1
i=1 i
Meaning
e = E[T]
= 1= E[T]
e = E[T], v = VAR[T]
pi = probability
for branch i,
ki; i = parameters of
the Erlang distribution
in branch i
the le lename
contains a numerical
n
lename
density generated by
(see section 8.2)
the program CAPP
The parameters have to be separated by spaces in the input eld.
Loop type
Species the type of branch for cyclic and loop nodes [Som90]. For all other node
types this eld is ignored. PEPP provides the following loop types:
{ c loop type constant
The probability for each loop entry is always p (see g. 3.4).
{ m loop type min{linear
The loop is executed at least min times. After that, the probabilities for the
min+1-th loop entry up to the max-th loop entry decrease in a linear way (see
g. 3.4).
{ p loop type p1{linear
The probability for the rst loop entry is p1. For the following loop entries up
to the max-th loop entry the probability decreases linearly after each iteration
(see g. 3.4).
{ g loop type general
min iterations have to be executed denitely. The probability for each additional loop entry must be specied separately (see g. 3.4).
{ u loop type uniform
The number of iterations is uniformly distributed. The parameters min (min.
number of iterations) and max (max. number of iterations) are needed here.
max = ?1 means that the max. number of loops is unlimited.
3.1. THE CANVAS MENU
17
pi
pi
p
1
1 2 3
pi
9 10
constant loop type
i
1 2
1
1
pi
min
max
general loop type
i
p1
1 2
min
max
min-linear loop type
i
1 2
max
p1-linear loop type
i
Figure 3.4: Dierent loop types
Loop params
Species the parameters of the selected branching type (see parameter Loop type).
Loop type Parameters
Range
Meaning
c
p
0p<1
probability for
all loop entries
min = min. number
m
min max
0 min < max < 200
of loop entries
max = max. number
of loop entries
p1 = prob. for
p
p1 max
0 p1 < 1;
rst loop entry
1 < max < 200
max = max. number
of loop entries
min = min. number
g
min p1 : : : pn
0 min < 200;
of branches
0 pi < 1;
pi = prob. for
0 n < 20
loop entry min + i
min = min. number
u
min max
0 min
of loops
min < max or max = ?1 max = max. number
of loops
CHAPTER 3. MODEL CREATION
18
The parameters have to be separated by spaces in the input eld. For the loop
types min{linear, p1{linear, and general there are some restrictions for the number of
iterations, since in some cases too many iterations could lead to problems evaluating
the model (time and memory). Therefore the maximal number of loops is restricted
to 199.
Node name
Species the node's name with a maximal length of 255 characters. This name is
used as the source reference of the node, which is the name of a program activity
modeled by the node. The node name is needed for instrumentation (see section 4),
validation (see section 6), and trace analysis (see section 7) For model{driven
instrumentation with AICOS the node name must be a procedure name!
Processor
Species the processor or process on/in which the node is executed. The name may
consist of max. 255 characters. For parallel nodes, a list of processor/process names
separated by single apostrophes (') is expected. Double the apostrophe to use it
inside a name. The processor name is needed in addition to the node name for
instrumentation (see section 4), validation (see section 6), and trace analysis
(see section 7).
Node label
Source file
Species an optional short label (max. ve characters) for the node. This label
appears inside the node in the drawing canvas.
Species the name of the le in which the source code of the program activity to be
modeled can be found.
If all parameters of the node have been specied, the node is created by pressing the
RETURN{key in the last input eld or by clicking the left mouse button on Create. If
Cancel is clicked, no node is created.
When an error was found in the node parameters, a warning window appears and the
user has to correct the parameters. All warning windows must be conrmed by pressing
the left mouse button on the OK{button or by pressing the Return{key inside the warning
window.
For a new node a rectangle containing two lines of text appears in the canvas (see g. 3.5).
The upper line consists of the node's label and the node's type. The lower line gives
the runtime distribution type and the distribution parameters (except for mixed Erlang
distribution and numerical distribution).
3.1. THE CANVAS MENU
19
INIT P 6
e 1.5
Zl
a 2.3 0.5
CALC E
b
Figure 3.5: Dierent nodes
Hierarchical nodes are marked with an additional rectangle inside the outer rectangle.
Loop nodes are marked with a loop frame inside the outer rectangle (see g. 3.6). Empty
hierarchical nodes have a diagonal line across the rectangle to indicate that no subgraph
exists. When a subgraph has been dened, this line disappears.
sub-1
sub-1
loop
Figure 3.6: Hierarchical nodes
3.1.1.2 Create Edges
To create an edge, the left mouse button must be pressed inside the start node of the
edge. When moving the mouse while keeping the button pressed, a line appears which can
be dragged to the destination node. Releasing the mouse button inside the destination
node creates the edge. It is not possible to create edges starting and ending at the same
node or to create multiple edges between two nodes. Edges that lead to a cycle cannot be
created, because PEPP can evaluate acyclic graphs only.
PEPP oers dierent types for the graphical representation of edges in the drawing canvas.
The actual edge type can be selected in a popup menu (see section 3.2.3).
3.1.1.3 The Help Function
There is a context{sensitive help function for the input of node parameters. The help
function is activated by pressing an arbitrary mouse button inside an input eld. Help is
implemented in two ways: a list of names from which one name can be selected with the
mouse or a text window describing the possible parameters and their values. To select an
item from a list of names click on the item. The corresponding text is automatically lled
into the input eld and the help window closes.
For the input elds Node type, Distr. type, Loop type, Processor, and Source file
a list is dened, for the input elds Distr. params and Loop params a help text is
dened, which depends on the selected distribution type, respectively loop type.
CHAPTER 3. MODEL CREATION
20
3.1.2
Change:
Change Node Parameters
Using the function Change, the parameters of existing nodes can be changed. To change a
node the left mouse button is pressed inside the node. A parameter window containing the
actual node parameters appears. The parameter elds are the same as in the parameter
window of the Create function described in section 3.1.1.1.
Pressing Change the new parameters are stored in the node. For input elds where no
changes were made the old values are restored. Using Cancel the function Change is left
without changes.
3.1.3
Delete:
Delete Nodes and Edges
With the function Delete nodes and edges can be removed. To delete a single node or
edge, click the left mouse button inside the node or on the edge. Then a popup window
appears in which the deletion must be conrmed with Delete or ignored with Cancel.
When deleting a node all edges connected to this node are deleted, too.
To delete a group of nodes, a rectangle can be created with the mouse to mark the nodes
which should be deleted. With the left mouse button pressed outside of all nodes and
not upon edges, the rectangle denition starts. Moving the mouse while pressing the left
button opens the rectangle. All nodes which are fully inside the rectangle upon button
release are marked for deletion. A popup window appears in which the deletion of the
group must be conrmed. All marked nodes and all edges connected to these nodes are
deleted.
The last deletion of nodes or edges can be undone with the function Undo (see section 2.2.1.3).
3.1.4
Copy:
Copy Nodes
Using the function Copy, new nodes can be created which are identical to existing ones. A
set of identical nodes (all node parameters are identical) which is often used when modeling
a regular structure can be created quickly with this function. Copy works recursively on
hierarchical graphs, copying all reachable subgraphs.
Nodes are copied in the following way:
1. Select a node by pressing the left mouse button inside the node and holding the
mouse button pressed.
2. A new node appears slightly moved to the original node. This node can be dragged
with the mouse to a new position.
3. Releasing the left mouse button places the new node. If the mouse button is released
while the new node overlaps with an existing node, no new node will be created.
3.1. THE CANVAS MENU
21
To copy a group of nodes, a rectangle can be created with the mouse to mark the nodes
which should be copied. Pressing the left mouse button outside of all nodes and not upon
edges the rectangle denition starts. Moving the mouse while the button is pressed opens
the rectangle. All nodes which are fully inside the rectangle and all edges between these
nodes upon button release are marked for the copy operation. The marked nodes and
edges can be copied by pressing the left mouse button inside the dened rectangle as it
is done for a single node. If one of the new nodes overlaps with an older node at the end
of the copy operation, no new node will be created.
3.1.5
Copy Into:
Copy Node Parameters
Using the function Copy Into, the distribution and loop parameters of one node can be copied into another existing node. The parameter node label, node name, and processor
of the destination node are not changed. This function can be used to quickly change the
parameters of many nodes.
Copying node parameters works as follows:
1. Select a node from which the parameters should be copied with the left mouse
button and hold the button pressed down.
2. A node rectangle appears slightly moved to the selected node, this node can be
dragged with the mouse to another node.
3. Releasing the mouse button inside the destination node copies the distribution parameters of the source node into the destination node. If the mouse button is released
outside a node, the dragged rectangle disappears without copying any parameters.
It is not possible to copy parameters from or to a hierarchical node, only non{hierarchical
nodes are allowed as source or destination.
CHAPTER 3. MODEL CREATION
22
3.1.6
Edge Probability:
Create Branching Edges
With the function Edge Probability a normal task dependence edge can be converted
into a branching edge by dening a branching probability for the edge. With branching
edges program structures such as if-then-else or switch-case can be modeled.
p1
p2
pn
Branch11
Branch21
Branchn1
Branch1k
Branch2l
Branchnm
Figure 3.7: Admissible branching structure
Using branching edges, the following restrictions concerning the graph structures must be
considered (see g. 3.7):
1. There must be at least two branching edges starting at a node.
2. The branches must all join in the same end node.
3. A branch has to consist of a chain of serially combined nodes.
All edges starting at the start node must have assigned a branching probability. The sum
of all probabilities must be 1.
3.1. THE CANVAS MENU
23
The number of nodes in the branches can dier for every branch. If a branching structure
inside a branch has to be modeled, a hierarchical node must be used in the outer branch
whose subgraph contains the inner branching structure.
To assign a branching probability to an edge, the edge must be selected with the left
mouse button. Then a window appears to enter the probability:
Probability: The value of the edge probability p with 0 < p 1 must be given.
Set:
Cancel:
Using p = 1 denes a normal task dependence edge.
Store probability for edge.
Leave the function without changing the edge's probability.
If a correct probability was specied, the edge is labeled with this probability in the
drawing canvas. Note that PEPP checks the correctness of the specied probability value.
Therefore the last probability value of a branching structure is automatically assigned by
PEPP, guaranteeing that the sum of all probabilities is one.
3.1.7
Mapping:
Assign Processor/Process Names to Nodes
For trace analysis and validation of event traces the mapping of the modeled program
onto dierent processors or processes must be known. Using the function Mapping, a
name specifying the processor/process on/in which the corresponding task is carried out
can be assigned to every node.
Figure 3.8: The mapping window
After the activation of this function, the mapping window appears on the screen (see
g. 3.8) and the drawing canvas changes to the mapping mode, where all already mapped
nodes are represented by a bold style rectangle containing the node label and the mapping
conguration. The mapping window provides a list of all available processor/process names. The entries of this list can be selected by clicking the left mouse button. The selected
names are displayed in reverse video and can be assigned to any arbitrary node by pressing
CHAPTER 3. MODEL CREATION
24
the left mouse button inside the node. The mapping can be undone by pressing the left
mouse button again. The assignment of more then one name to a node is only possible
for parallel nodes. Furthermore, the mapping window contains a text input eld, where a
list of new processor/process names can be inserted. The names must be separated from
each other with a single apostrophe ('). The new names will be inserted in the above list
by pressing the RETURN{key. Finally, there are several buttons in the mapping window,
which support the mapping procedure:
Clear Selection: Un-highlight all selected names in the list.
Unmap :
Unmap all nodes. This function has to be conrmed.
Remove :
Remove the selected names from the list. This function has to be
conrmed, too.
Leave mapping mode and close the mapping window.
Done :
Note that a processor name can already be dened while creating a node (see section 3.1.1.1) or with the function Change (see section 3.1.2). This name will automatically
be added to the list of processor/process names.
3.1.8
Show Density:
Graphical Display of Numerical Densities
With the function Show Density the density of the runtime distribution of a node can be
displayed with the program CAPP (Calculation And Presentation Package). When the
left mouse button is pressed inside a node, its density function is displayed by CAPP. It
is required that the program CAPP is already running. The usage of CAPP is described
in section 8.2.
3.2 Functions in the Drawing Canvas
The functions described in the following sections are independent of the function selected
in the main or canvas menu.
3.2.1 Enter and Exit a Subgraph
To enter the subgraph of a hierarchical node the Shift{key or the Control{key together
with the left mouse button being inside the hierarchical node have to be pressed. The
subgraph of the node appears inside the drawing canvas.
The status line above the canvas shows the current location inside the hierarchy of the
graph model. When located in the main graph the following line appears:
Graph:
lename
3.2. FUNCTIONS IN THE DRAWING CANVAS
25
If no lename is dened for the current graph, main is used as name.
Inside the subgraph subgraph n the full hierarchy represented as the path from the main
graph to the current subgraph is displayed:
Subgraph: lename->subgraph 1->
: : : ->subgraph n
To quit a subgraph and change to the parent graph, i.e. to step up one hierarchy level,
click on the status line with the left mouse button. If already in the main graph clicking
on the status line is ignored.
3.2.2 Move Nodes
While pressing the middle mouse button inside a node, this node can be moved around
with the mouse. The edges connected to the node are moved automatically, too.
To move a group of nodes, a rectangle is created with the mouse to select the nodes for a
following move operation: with the middle mouse button pressed outside of all nodes the
start point of the rectangle is dened. Moving the mouse while pressing the button opens
the rectangle. All nodes which are inside the rectangle upon button release are selected
for the following move operation. Pressing the middle mouse button inside the dened
rectangle starts the moving of the group of nodes as for a single node.
3.2.3 Select Edge Type and Redraw Canvas
By pressing the right mouse button outside of all nodes a selection menu appears where
the edge type for new edges can be selected. An item is selected by pressing the left mouse
button at the item. The selected edge type is used during all following create operations.
Fig. 3.9 shows the dierent edge types that PEPP oers:
Figure 3.9: The dierent edge types
In addition to the edge type selection, the canvas display can be refreshed with Redraw
OR or Redraw XOR. A selection of one of these two functions also denes the draw mode
to use (OR or XOR). Normally, the canvas is refreshed automatically by PEPP. Redraw
OR is useful when an X-window screen dump should be made because 'holes' in nodes and
edges disappear in OR{mode. You should select XOR{mode for normal work because
with OR{mode single points may not be erased when moving nodes. Furthermore, the
26
CHAPTER 3. MODEL CREATION
function allows to change the type of an already created edge. After the
activation of this function, you can change the type of one edge to the current type by
selecting the edge with the left mouse button. Clicking at Change Layout is the same as
selecting the function Change in the canvas menu.
Change Layout
3.2.4 Display Node Parameters
To display all parameters of a node press the right mouse button inside the node. Then
a popup window with the node parameters appears and keeps displayed until the mouse
leaves the window or the mouse button is pressed again.
In addition to the node parameters known from the parameter window of the functions
Create (see section 3.1.1.1) and Change (see section 3.1.2), the additional parameters
Source line, Event number, Event time, and Occurrences are displayed. This parameters are set during the validation of an event trace and contain information that is
relevant for debugging purposes (see section 6).
Finally, the node parameter window contains the parameters Mon. Stat. 1 and
Mon. Stat. 2, which can be set during instrumentation (see 4.1).
4 Program Instrumentation
Program instrumentation is necessary for event{driven monitoring using software or hybrid monitoring. Using one of these monitoring methods events are dened by inserting
so{called monitoring instructions for supporting monitoring. The insertion of these instructions is called program instrumentation. As hardware instrumentation is not mentioned in this context, program instrumentation is just called instrumentation for short.
With model{driven monitoring, the monitoring model is the basis for the instrumentation
of the program to be monitored. The dicult questions 'What should be measured?' and
'Where should the program be instrumented?' are answered by building the monitoring
model. Program activities represented in the model will be instrumented. Model{driven
instrumentation and its advantages are described in [KQS92].
This section introduces how the model generated with PEPP is used to automatically
dene instrumentation points and to create a command le for further use with an instrumentation tool. For instrumentation of programs written in the programming language C
(short: C{programs) the tool AICOS is used. AICOS takes the command le generated by
PEPP and inserts monitoring instructions into the source code of the C{program. Before
execution and monitoring, the instrumented program must be compiled.
For dening instrumentation points in the model, the nodes in the model must have the
same name as the corresponding program activities (e.g. procedures) to be instrumented.
Nodes without names cannot be instrumented.
4.1
Instrument:
Dene Instrumentation Points
With the function Instrument in the canvas menu, instrumentation points can interactively be created in the model. For each node an instrumentation point can be dened
for the entry and/or the exit points. The name of the node denes the corresponding
program part. Usually a procedure or function is modeled by a node so that the name of
the node corresponds to the name of a procedure or function in the program.
To dene an instrumentation point, press the left mouse button inside the node. Clicking
in the upper half of the node sets the entry instrumentation point, clicking in the lower
half sets the exit instrumentation point. By clicking again on an instrumentation point
the point will be removed. When an instrumentation point is set or removed, the whole
graph is searched for nodes with identical name and identical source le. If a node with
the same name and source le exists, the selected instrumentation point is also set or
removed in that node.
27
CHAPTER 4. PROGRAM INSTRUMENTATION
28
For each instrumentation point, a small lled rectangle appears inside the node (see
g. 4.1). A rectangle in the upper half of a node indicates the instrumentation of the
entry point and a rectangle in the lower half indicates the instrumentation of the exit
point.
instr E
e 1.5
entry
instr E
e 1.5
exit
instr E
e 1.5
entry and exit
Figure 4.1: Instrumented nodes
During the instrumentation process, monitoring instructions are being assigned to each
instrumentation point. It is possible to assign dierent monitoring statements to each
instrumentation point. For changing the monitoring statement, press the left mouse button outside all nodes. Then, a dialog window appears where you can specify the new
monitoring statement (see g. 4.2).
CHANGE MONITORING STATEMENT
Default Stat.:
trace(%e);
^
Monitoring Stat.: trace(%e,%f,%l);
Change
Default
Cancel
Figure 4.2: Change monitoring statement
The rst text eld contains the default monitoring statement which is taken from the
resource le Pepp. In the other text eld you can insert the monitoring statement you
want. Pressing the RETURN{key or clicking the left mouse button on Change, the window
disappears and the new statement will be stored for all following instrumentations. If you
want to use the default statement, click on the Default{button. If Cancel is clicked, the
window disappears and the changes will be ignored. You can control which monitoring
statement has been assigned to an instrumentation point by pressing the right mouse
button inside a node (display of node parameters; see 3.2.4). The parameter window
contains two monitoring statements. The rst one is for the entry point (Mon. Stat. 1)
and the second one will be inserted at all exit points of this node (Mon. Stat. 2). Finally,
there is a help window for this function which appears after pressing a mouse button inside
the second text eld.
4.2.
INSTRUMENTATION:
4.2
CREATE AN INSTRUMENTATION COMMAND FILE
Instrumentation:
Command File
29
Create an Instrumentation
The function Instrumentation in the main menu is used to create a command le for
automatic program instrumentation with AICOS (see section 4.3). In the dialog window
the le name of the command le has to be specied and the instrumentation mode must
be selected.
File:
Name of the instrumentation command le which should be
created (default: the name of the model le with the extension
.acf, aicos command file).
Object System:
Name of the object system on which the measurements will be
executed. If you press an arbitrary mouse button inside this
eld, a selection menu appears where you can select an object
system (see also 4.3.2).
Instrument Nodes: Instrument all entry and exit points of all named nodes independent of whether the points are explicitly specied or not.
Instrument Points: Instrument points specied with the function Instrument only.
Cancel:
The instrumentation function is left without any eect.
The instrumentation commands as well as the monitoring instructions are denable by
the user. In the last section we showed how to change the monitoring statement. The
instrumentation commands are taken from the resource le Pepp (see section 9).
For each unique node name in the model, the following commands are stored in the
command le:
If entry and exit points of a node should be instrumented, PEPP produces:
#BEFOREAFTERCALL nodename
trace1
trace2
If only entry points of a node should be instrumented, PEPP produces:
#BEFORECALL nodename
trace1
If only exit points of a node are instrumented, PEPP produces:
#AFTERCALL nodename
trace2
In addition to the above instrumentation commands, a list of all processor names used in
the model is included in the command le in the following format:
CHAPTER 4. PROGRAM INSTRUMENTATION
30
#PROCESSOR
processor1
#PROCESSOR
processor2
...
#PROCESSOR
processorn
!!
Further, the command le created by PEPP contains the specication of the object system
on which the measurements will be executed. This additional information is used by
AICOS for constructing a TDL{le fragment later on, useful to create a complete event
trace description in TDL necessary for validation and analysis of an event trace. The
syntax of TDL is described in [Moh92]).
4.3 Automatic Instrumentation with AICOS
The program AICOS (Automatic Instrumentation of C programs) can be used for automatic instrumentation of C{programs [Ber88, Mil90]. The insertion of a monitoring
instruction is possible at any point in the program where an instruction is syntactically
correct. With model{driven monitoring only instrumentation of procedures is possible.
The monitoring instruction depends on the monitoring system used. It is possible to
insert any desired C{statement.
The instrumentation with AICOS can be subdivided into the following steps:
1.
2.
3.
4.
5.
execution of all C{preprocessor statements (see cpp(1))
syntactical analysis of the C{program
creation of the parse tree and the symbol table
insertion of the monitoring instruction into the parse tree
transformation of the modied parse tree into a new and instrumented C{program
As AICOS executes all C{preprocessor statements and removes all comments in the program, it should be used as a lter program which is executed after editing the program
to be monitored. The output of AICOS, the instrumented program, is not suited for further editing. The program to be instrumented will not be changed, but a new le, the
instrumented program, will be created. The instrumentation with AICOS is carried out
at source code level so that the instrumented program has to be compiled before it can
be executed and monitored.
4.3. AUTOMATIC INSTRUMENTATION WITH AICOS
31
4.3.1 Invocation of AICOS
The tool AICOS oers two modes for instrumentation:
menu driven interactive mode:
The instrumentation is based on inputs from the user.
command mode:
The instrumentation is based on a command le in which all instrumentation commands for AICOS are stored. The command le can be created in dierent ways.
For details and the syntax of the command le see below.
The synopsis of AICOS is:
AICOS
[
options ]
[
input le.c ]+
In the command line the input les input le.c must be correct C{programs. AICOS creates for each input le an instrumented C{program input le.i. The instrumented program
must be compiled with cc(1) before execution.
Valid options are:
-D
-D
-I
-U
-a
Dene name as 1 (one). This is the same as if a '-D name=1' option appeared on the cpp command line, or as if a #define name 1 line appeared
in the source le that cpp is processing (see cpp (1)).
name=def Dene name as if by a #define directive. This is the same as if a
'#define name def' line appeared in the source le that cpp is processing. The -D option has lower precedence than the -U option. That is,
if the same name is used in both a -U option and a -D option, the name
will be undened regardless of the order of the options (see cpp (1)).
directory Insert directory into the search path for '#include' les with names not
beginning with `/'. directory is inserted ahead of the standard list of \include" directories. Thus, '#include' les with names enclosed in doublequotes (") are searched for rst in the directory of the le with the
'#include' line, then the directories named with -I options, and lastly,
in directories form the standard list. For '#include' les with names enclosed in angle-brackets (<>), the directory of the le with the '#include'
line is not searched (see cpp (1)).
name
Remove any initial denition of name, where name is a symbol that is
predened by a particular preprocessor. For further details see cpp (1).
monitoring instruction The instruction monitoring instruction will be inserted at
each given point in the program. monitoring instruction can be any correct C-statement. In order to distinguish between the dierent events
there must be a clear assignment between the event tokens and the
events. Therefore the event tokens can be created automatically using
the global event counter or the event token counter. The following
counters can be used for instrumentation with AICOS:
name
CHAPTER 4. PROGRAM INSTRUMENTATION
32
global event counter
At each insertion of a monitoring instruction this counter will be
incremented by one. The value of this counter can be referred to
with the parameter %g.
event token counter
The event token counter will be incremented after each AICOS command. Using this counter for the instrumentation of a procedure the
beginning of this procedure will be instrumented with event token
i and all exit points of this procedure with event token i + 1.
The value of this counter can be referred to with the parameter
%e. If the corresponding event trace description in TDL should be
created automatically this counter must be used.
event number counter
This counter can be used to count the number of instrumentations
during one AICOS command and to distinguish between them. This
counter is reset to 0 whenever a new AICOS command is executed
and incremented by one on every inserted monitoring instruction.
Using this counter, there is no bijective mapping between the event
tokens and the events. It can be used just as a parameter using
the global event counter or the event token counter as an event
identication. The current value of this counter can be referred to
with the parameter %n.
Besides, AICOS supports further parameters (%l, %f, %0{%9) which are
explained below (see option -p).
-c
-f
-l
-n
value
Set the event token counter to value. value must be an integer value
greater than or equal to zero.
commandle If the option -f is used, the instrumentation will be carried out in
command mode. All instrumentation commands will be taken from the
command le given in the parameter commandle. When this option is
given, the option -a is suppressed. If the le commandle does not have
the sux .acf, it will be appended by AICOS automatically.
logle
Create a new command le during instrumentation in interactive mode.
All instrumentation commands are stored in logle. This option will be
ignored in command mode.
tracefunctionle Generate system dependent monitoring functions and store them
in tracefunctionle. System dependent monitoring functions will be created automatically, if monitoring statements contain a function name
trace.
4.3. AUTOMATIC INSTRUMENTATION WITH AICOS
33
Expand parameter variables in monitoring instruction. The following parameters are supported:
-p
%g
%n
%e
%l
global event counter
event number
event token counter
actual line number where the monitoring instruction will be
inserted
%f
actual le name of the source le to be instrumented
%0 return value of the instrumented function
%1-%9 parameter of the instrumented function
Each parameter may be followed by a separator, which must be either a
dot ('.') or a colon (':'), and by the number of bytes required for this parameter. The separator species whether the parameter is an integer ('.')
or a character string (colon). For example, in the monitoring instruction
trace(%e.2,%1:4);
the event token counter is a 2-byte integer and the rst parameter of the
instrumented function is a string with at least 4 byte.
If a trace description in TDL should be created, the event token counter
(%e) must be used as a parameter in the monitoring instruction. Note
that the parameter %l has to be used in the monitoring instruction, if
an event localization in the source code should be carried out during the
validation process (see section 6.3).
The option -p will be set automatically, if the option -t is used.
-t
tdlle
Create a TDL trace description le tdlle which is necessary for the access
of the trace produced by execution of the instrumented C{program under
investigation. The created le gets the name tdlle. If tdlle does not end
with the sux .tdl, this sux will be appended automatically.
The le tdlle is instrumentation dependent and monitor dependent. The
instrumentation dependent part concerns instrumented events, the processors/processes used, and the names of the underlying source les. All
monitor dependent denitions are xed in the template les zm4.tdl
and sw.tdl which are looked for before creating the tdlle. zm4.tdl is
for use with the distributed hardware monitor ZM4 [HKM+92], sw.tdl
is needed for software monitoring.
Both les contain the following placeholders:
denes an event
'$P' denes a processor
'$p' denes a process
'$F' denes a lename
'$E'
CHAPTER 4. PROGRAM INSTRUMENTATION
34
The program AICOS writes the information found in zm4.tdl or sw.tdl
to tdlle except the above placeholders, which are replaced automatically
by the corresponding event, processor/process, or lename token denition. In order to use the symbol '$' in a template le, the sequence '$$'
must be inserted in place.
The les zm4.tdl and sw.tdl must be in one of the following directories:
actual working directory
$KEYDIR
home directory
Turn on verbose mode.
-v
-w
seconds
During interactive mode the warnings will be displayed for 3 seconds.
This time can be changed with the option -w. The waiting time will be
set to seconds seconds. This option will be ignored in command mode.
4.3.2 The AICOS Command File Language
The command le used by AICOS can be obtained in three dierent ways:
during an execution of AICOS in menu driven interactive mode
from a graph model created with the program PEPP (see section 3) using function
Instrumentation
(see section 4.2).
create a new command le or modify an existing le with a text editor
Each line beginning with an exclamation mark '!' or with a slash '/' will be treated as
a comment. The backslash 'n' can be used as an escape sequence. Whitespaces at the
beginning of lines are ignored.
The following commands are supported by AICOS. Keywords are printed in bold face.
Parameters are printed in italic. mon instruction 1 and mon instruction 2 must be correct
C{statements. If there is only one monitoring instruction to insert, only one instruction
is allowed after the AICOS command. If there are two monitoring instructions to insert, two instructions (mon instruction 1 and mon instruction 2) must follow the AICOS
command. The lename species the source le in which AICOS should search for the
procedure procedurename. If lename is '*', AICOS searches for procedurename all input
les.
#MONINIT
Initialization of monitoring with the statements MonBegin
the procedure main of the program to be instrumented.
();
and MonEnd
();
in
4.3. AUTOMATIC INSTRUMENTATION WITH AICOS
35
#BEFORECALL procedurename lename
mon instruction 1
Instrumentation before all calls of the procedure procedurename in the le lename.
The instruction mon instruction 1 will be inserted.
#AFTERCALL procedurename lename
mon instruction 1
Instrumentation after all calls of the procedure procedurename in the le lename.
The instruction mon instruction 1 will be inserted.
#BEFOREAFTERCALL procedurename lename
mon instruction 1
mon instruction 2
Instrumentation before and after all calls of the procedure procedurename in the le
lename. The instruction mon instruction 1 will be inserted before all calls and the
instruction mon instruction 2 after all calls.
#BEGINPROCEDURE procedurename lename
mon instruction 1
Instrumentation at the beginning of the procedure procedurename in the le lename. The instruction mon instruction 1 will be inserted.
#ENDPROCEDURE procedurename lename
mon instruction 1
Instrumentation at all exit points of the procedure procedurename in the le lename. The instruction mon instruction 1 will be inserted.
#BEGINENDPROCEDURE procedurename lename
mon instruction 1
mon instruction 2
Instrumentation at the beginning and at all exit points of the procedure procedurename in the le lename. The instruction mon instruction 1 will be inserted at the
beginning and the instruction mon instruction 2 at all exit points of the procedure
procedure.
#BEFORELINE line number lename
mon instruction 1
Instrumentation before the line given in line number in the le lename. The instruction mon instruction 1 will be inserted.
CHAPTER 4. PROGRAM INSTRUMENTATION
36
#AFTERLINE line number lename
mon instruction 1
Instrumentation after the line given in line number in the le lename. The instruction mon instruction 1 will be inserted.
#BEFOREAFTERLINE line number lename
mon instruction 1
mon instruction 2
Instrumentation before and after the line given in line number in the le lename.
The instruction mon instruction 1 will be inserted before the line line number and
the mon instruction 2 after the line line number.
#BEFORECALLRANGE procedurename range beg range end lename
mon instruction 1
Instrumentation before all calls of the procedure procedurename in the specied
range in the le lename. The rst line of the range to be searched for calls of the
procedure procedurename must be given in range beg the last line must be given in
range end. The instruction mon instruction 1 will be inserted before all calls found
in the specied range.
#AFTERCALLRANGE procedurename range beg range end lename
mon instruction 1
Instrumentation after all calls of the procedure procedurename in the specied range
in the le lename. The rst line of the range to be searched for calls of the procedure procedurename must be given in range beg the last line must be given in
range end. The instruction mon instruction 1 will be inserted after all calls found
in the specied range.
#BEFOREAFTERRANGE procedurename range beg range end lename
mon instruction 1
mon instruction 2
Instrumentation before and after all calls of the procedure procedurename in the
specied range in the le lename. The rst line of the range to be searched for
calls of the procedure procedurename must be given in range beg the last line must
be given in range end. The instruction mon instruction 1 will be inserted before
all calls and the instruction mon instruction 2 after all calls found in the specied
range.
#PROCESSOR processorname
Dene a new processor name for the processor token.
#PROCESS processname
Dene a new process name for the process token.
4.3. AUTOMATIC INSTRUMENTATION WITH AICOS
#OBJECTSYSTEM objectsystem
37
In order to be able to create object system dependent monitoring functions supposed
that the corresponding option -n has been set, you have to specify the object system
on which the program to be analyzed is executed. The following object systems are
supported:
{ SPARC-SW
{ SPARC
{ HP-SW
{ TRANSPUTERBUS
{ SUPRENUM
where SPARC-SW and HP-SW are for software monitoring on SPARC and HP
architectures. The other object systems require that the measurements are executed as hybrid measurements with the distributed hardware monitor system ZM4
[HKM+92].
38
CHAPTER 4. PROGRAM INSTRUMENTATION
5 Create ZM4 Conguration Files
In the last section, the automatic program instrumentation with PEPP was explained. The
next step is to select a monitoring method and to execute and monitor the instrumented
program in order to get an event trace. Model{driven monitoring can be executed as
hybrid monitoring or software monitoring. As with software monitoring it is dicult to
get a global view of a parallel and distributed system's behavior, hybrid monitoring is our
favorite method.
The function described in this section supports hybrid monitoring with the distributed
hardware monitor system ZM41. This function is not only assumed for beginners. It can
make the work with the ZM4 easier for experienced users, too.
5.1 Architecture of the Hardware Monitor ZM4
The ZM4 monitor system is structured as a master/slave system with a control and
evaluation computer (CEC) as the master and an arbitrary number of monitor agents
(MA) as slaves (see g. 5.1) [HKM+92]. The distance between these MAs can be up to
1,000 meters. Conceptually, the CEC is the host of the whole monitor system. It controls
the measurement activities of the MAs, stores the measured data and provides the user
with the powerful and universal toolset SIMPLE for evaluating the event traces, which is
described in section 7. The program PEPP also runs on the CEC.
The MAs are standard PC/AT-compatible machines equipped with up to 4 dedicated
probe units (DPUs). We use their expandability for conguring ZM4 appropriately to
the various object systems. Each MA provides processing power, memory resources, a
hard disk and additionally a network interface for access to the data channel. The MAs
control the DPUs and buer the measured event traces on their local disks. The DPUs are
printed circuit boards which link the MA and the nodes of the object system. The DPUs
are responsible for event recognition, time stamping, event recording and for high-speed
buering of event traces.
A local clock with a resolution of 100ns and a time stamping mechanism are integrated
into each DPU. The clock of a DPU gets all information for preparing precise and globally valid time stamps via the tick channel from the measure tick generator (MTG). Time
stamps in a physically distributed conguration may be adjusted after the measurement
according to the known wire length. While the tick channel together with the synchronization mechanism is our own development, we used commercially available parts for the
data channel, i.e. ETHERNET with TCP/IP. The data channel forms the communication
subsystem of ZM4 and it is used to distribute control information and measured data.
The ZM4's architectural exibility has been achieved by two properties: easy interfacing
and a scalable architecture. The DPU can easily be adapted to dierent object systems. Up
1
ZM4 is the German abbreviation for counting monitor 4 ("Zahlmonitor 4")
39
CHAPTER 5. CREATE ZM4 CONFIGURATION FILES
40
OBJ 1
... OBJ 4
OBJ 5
D
P
U
1
M
T
G
... OBJ 8 ... OBJ i ...
D
P
U
1
MA1
...
MA2
D
P
U
4
tick
channel
...
OBJ j
...
OBJ
j+15
D
P
U
1
...
D
P
U
4
distributed
object system
ZM4
MAn
minimal
configuration
data channel
CEC
Figure 5.1: Distributed Architecture of ZM4
to now interfaces have been built for SUN-4, DIRMU, Transputer, IBM PC, SUPRENUM
and some embedded systems. ZM4 is fully scalable in terms of MAs and DPUs. The
smallest conguration consists of one MA with one DPU (see g. 5.1, left), and can
monitor up to four object nodes. Larger object systems are matched by more DPUs and
MAs, respectively.
5.2
Monitor:
Create ZM4 Conguration Files
Before the execution of an instrumented program on a system which is equipped with a
ZM4 conguration, some preliminary work has to be done. For example, to start the MTG
or the DPUs of one monitor agent there are some special commands (mtgstart, dpustart,
and dpuread) which must be executed on each MA. Some of the commands require options
which specify characteristics of the ZM4 conguration, e.g. number of DPUs, number of
event streams and their width. When the measurement is nished, the monitored event
traces have to be copied to the CEC. One possible solution to reduce this eort is to
use MSDOS batch les (.bat les) for each MA, which execute the commands that are
necessary for executing a measurement. With PEPP, these batch les can be created
automatically.
To invoke this function, the main menu button Monitor must be activated rst. Then, a
dialog window comes up where you can specify the following parameters:
Processors:
A list of processor names separated by single apostrophes (') must be specied.
Double the apostrophe to use it inside a name. This list should contain the names
of all processors which should be monitored. If you click any mouse button inside
5.2.
MONITOR:
CREATE ZM4 CONFIGURATION FILES
41
this eld, a menu with the names of all processors of the actual model appears. This
is similar to the processor eld of the Create box described in section 3.1.1.1. If no
name is specied, all mapped processors are monitored.
Object System:
Batch Generator:
Merge Program:
The object system, i.e. the system on which the instrumented program runs, must
be specied here. A help menu with a list of all supported object systems can be
invoked by clicking with a mouse button inside this eld. Only these systems are
allowed.
In this eld, a name of a UNIX shell script to be created must be inserted. Executing
this script, a MSDOS batch command le is created for each monitor agent. Invoking
the batch les at the monitoring agents starts the measurements. The batch le at
MA1 must be invoked last. Before starting the measurement, the batch les must
be copied to the MAs (with ftp(1) or rcp(1)).
When the measurement is nished, the recorded event traces will be copied to the
CEC by the created batch les. The next step is to merge all local event traces into
a global event trace. This can be done by another shell script, whose name must be
specied in this eld.
Trace Directory:
Host:
Target directory where the recorded event traces should be copied.
Name of the host (CEC), on which the trace directory exists and to which the event
traces should be copied.
By pressing the Create button, the two shell scripts will be created. With the Cancel
button this function is left without any eect.
42
CHAPTER 5. CREATE ZM4 CONFIGURATION FILES
6 Consistency Validation
With PEPP, the consistency between the monitored program behavior and the behavior
represented in the monitoring model can be validated, i.e. the event order in the monitored
event trace is checked against the model. Validation is necessary in order to draw correct
conclusions from trace analysis. This kind of validation provides hints for nding program
errors.
With model{driven instrumentation, the sets of events are the same in monitoring and
modeling. Measuring the instrumented program leads to an event trace which can be
checked against the modeled behavior [DKQ92, Kie91].
During the consistency check the following tests are carried out:
1. The node names are checked against the event identications of the event records
in the event trace.
2. The processor/process specied in a node is compared with the processor/process
given in the event record of the event trace.
3. The source le name specied in a node must be equal to the source le name given
in the corresponding event record.
While the rst test of the list above is carried out with each consistency validation |
without this test no validation is wise | the second and third test are only performed if the
given event trace contains the necessary data, i.e. information about the processor/process
and about the source le name for each event record.
Additionally, the validation process and event trace analysis by X-window based evaluation tools of the event trace evaluation environment SIMPLE (see section 7) can be
carried out in a synchrouous way. By means of this synchronization, we achieve that the
functional validation process is extended to a performance validation process [Dau94].
6.1
Validation:
Start Validation
Validation can be started by pressing the validation button in the main menu. A window
in which the functions for a trace validation can be selected will be opened.
The validation menu contains the following functions:
Init Trace:
Initialize an event trace for a following validation. A key le (.key) and a trace le
(.trc) are required. If only one of these les is specied then the other le name
is built automatically by appending the corresponding sux to the rst name. An
initialized trace stays active until another trace is selected by Init Trace.
43
CHAPTER 6. CONSISTENCY VALIDATION
44
The event records in a trace must fulll the following conditions which are checked
when a trace is opened for validation (for the event trace description language TDL
see [Moh92]):
{ The event token is expected in the eld EVENT of type TOKEN or FLAGS.
{ The processor name is expected in the eld PROCESSOR or PROCESS of type
TOKEN or FLAGS. If there is neither a PROCESSOR nor a PROCESS eld then
the processor name of each event is set to undened processor. In this case only
models without processor names can be used.
{ The line number of each event is expected in the eld LINE NUMBER. This should
be an ordinary DATA eld of type INTEGER.
{ The source le name is expected in the eld FILE NAME. These eld should be
of type TOKEN or FLAGS.
If one of the elds is missing, the corresponding value in every event is set to undened and it is not possible to establish a connection between an event or node and
the source text of the program.
Quick Validation
Validate the consistency between the event trace and the model without graphical
display during validation. First, it is checked whether the sets of events in the
model and the event trace are identical, second the event trace is checked against
the model. At the end of the validation the results are displayed in a new window
(see section 6.3).
Animated Validation
Validate an event trace with graphical display of the validation progress after each
event processed. In contrast to Quick Validation, this function displays the progress of the validation step by step in the graph model. To control the animated
validation, a window with the following functions comes up:
:
Delay:
Start
:
Breakpoint
:
Break
:
Continue
:
Cancel
Start the validation.
Delay between the processing of two subsequent events in 1/10th
seconds.
Dene an event where the validation should stop automatically.
The validation stops after processing this event. A breakpoint
may be dened by either an event record number, i.e. an integer,
or an event name, i.e. an event interpretation known from the
trace description.
Stop a running validation to inspect model state.
Continue a stopped validation.
Stop the validation and close the control window.
Breakpoints can be used to validate a number of events in quick mode (Delay = 0)
and continue after the breakpoint with Delay > 0. During a running validation,
the user can select the visible part of the canvas window with the two scrollbars,
subgraphs of hierarchical nodes can be entered and left.
6.2. SYNCHRONIZING VALIDATION AND TRACE ANALYSIS
45
Quick Validation + Trace Analysis
Animated Validation + Trace Analysis
These functions oer the same functionality as the functions Quick Validation and
Animated Validation described above. Additionally, these functions are capable of
managing and controling the evaluation progress of SIMPLE's event trace evaluation tools which are started with the X11-Motif driver 'x11Mstepwise' currently
supported by the SIMPLE evaluation tools gantt (see gantt(1)) and hasse (see
hasse(1)) ([Dau93]). While passing through the event trace during the consistency
check carried out by the validation, trace analysis results to be computed by event
trace evaluation tools are presented step by step. This coordination of the validation
and trace analysis progress allows to associate evaluation results to certain parts of
the model and the program. The coordination mechanism is described in detail in
section 6.2
Clear Marking
Clear all node markings in the graph model. After a validation is nished, the nodes
of the graph model are marked representing the state reached during the validation
(see section 6.3). Using Clear Marking, all node markings are reset to the initial
state. The node markings are reset automatically before a new validation starts.
6.2 Synchronizing Validation and Trace Analysis
During model-driven validation of an event trace against the monitoring model of the
program, only functional errors can be detected. It is checked whether the sequence of
events in the monitored event trace follows the causal dependencies given in the model.
Event trace evaluations, such as statistical calculation of task durations, the frequency
of events, or behavior-oriented computations (like Gantt charts) are carried out after the
validation process has been completed.
This way of evaluating parallel programs is correct and obvious, but it leaves a lot of
dicult work to be done by the user. Performance problems indicated by an evaluation
tool must be directly associated to the corresponding program part in order to correct
or to improve the program. Evaluation results are meaningless if the user gets no idea
how and where to change the program. Here, a problem-oriented reference between an
event and a point in the program, as dened with model-driven monitoring, does not help
either | it just helps to nd functional errors. The strict separation of validation and
evaluation, however, implies that performance errors detected during the evaluation of an
event trace cannot be attached easily to specic parts of the model or program. In order
to overcome this problem our solution is to integrate event trace analysis with event trace
validation [Dau94].
Common to validation and evaluation of event traces is stepping through the event trace
from beginning to end. The only demand for combining both processes is to guarantee
their synchronous advancement through the event trace. Then, for example, the cause of
an idle time revealed in a dynamic Gantt chart built up during the combined validation
and evaluation process, can easily be localized in the model and in the program, because
CHAPTER 6. CONSISTENCY VALIDATION
46
at the moment when the evaluation tool indicates an idle time, the validation is also
exactly in the corresponding part of the model. This gives us an enormous improvement
in performance debugging. It enables us to map current evaluation results to specic parts
of the model and program.
The synchronization of the validation process with the evaluation process is done via
the X-protocol. Pepp and all tools that can be controlled by pepp during the combined
validation-evaluation process are stand-alone programs - in the X window terminology
they are independent X-clients. The synchronization works according to the master-slave
concept, where pepp is the master and all evaluation tools are slaves. The master, i.e. pepp,
noties each slave when it should go ahead one event record in the given event trace. We
say: The master triggers the slaves. The trigger-communication is carried out via the X
window protocol using the available mechanism of properties appended to the X-server's
root window.
The communication works according to the following protocol (see g. 6.1):
request for trigger connection
confirm trigger event
evaluation
tool
PEPP
send trigger event
terminate trigger connection
reset trigger connection
Figure 6.1: Communication protocol between pepp and evaluation tools during the validation process
1. Open a trigger-connection with pepp:
Each evaluation tool which wants to be synchronized to the validation process
has to open a trigger connection to pepp. An evalution tool noties pepp
about its request for a trigger connection by writing onto the property SIMPLE OPEN TRIGGER ATOM that is listened by pepp. This enrollment for
participating in the communication will be not conrmed by pepp.
6.3. RESULTS OF VALIDATION
47
2. Close a trigger-connection with pepp:
When an evaluation tool exits, it has to notify pepp that it no longer takes part
in the synchronization. This termination of a trigger connection is carried out by
the evaluation tool writing the property SIMPLE CLOSE TRIGGER ATOM.
This notication of leaving will also be not conrmed by pepp.
3. Communication via an established trigger-connection with pepp:
An established trigger connection between an evaluation tool and pepp is used
both for sending trigger events from pepp to the evaluation tool(s) and for the
evaluation tools' conrmation of received trigger events. By the property SIMPLE NOTIFY TRIGGER ATOM pepp says to an evaluation tool to move forward one event record. The value written onto the property is the stepcounter.
The notied evaluation tool must conrm this notication by writing the SIMPLE RESULT TRIGGER ATOM property.
4. Reset an established trigger-connection with pepp:
If the validation process is restarted by the user, the connected evaluation tools must also be restartet, in order to keep the validation and the
evaluation synchronized. This is caused by pepp writing the property SIMPLE RESET TRIGGER ATOM, which must be conrmed by each evaluation
tool writing the SIMPLE OPEN TRIGGER ATOM again.
In the synchronization of validation and evaluation, pepp has the task to manage the
synchronization of dierent evaluation tools and itself. Therefore, it is a prerequisite that
pepp is called before any evaluation tool to be managed is invoked. In other words: evaluation tools which are started before pepp is called cannot be correctly considered during
the performance validation process. If pepp terminates, the managed evaluation tools will
also be terminated.
The combined validation-evaluation process is designed to control an arbitrary number
of evaluation tools at a time. The synchronization is carried out via the default set of
X-properties given above. Sometimes it is convenient to synchronize dierent tools via
dierent properties. To allow this, the option -P is available (see section 2).
6.3 Results of Validation
After a validation | either simultanuous with some performance evaluations or not | is
nished, the results are displayed in a special text window and also in the drawing canvas:
Results presented in the text window:
In a text window the result of the validation is displayed. For a correct event trace
the message Trace matches model appears. If an error occurred during validation,
rst the event which caused the error is displayed. Second, the lename and line
number of the erroneous event is shown. Last but not least, the error situation is
described if an error classication is possible.
CHAPTER 6. CONSISTENCY VALIDATION
48
Results presented in the drawing canvas:
All nodes in the model are marked with their actual processing state. The upper
part of a node is marked corresponding to the call{event and the lower part corresponding to the return{event. If a node has assigned no event or only one event,
the upper and lower parts of the node are marked always with the same state. There
are ve dierent node states (cf. g. 6.2):
Figure 6.2: Dierent node markings
:
unprocessed
:
ready
:
processed
:
skipped
:
error
not marked. Nodes are not yet processed.
marked with light hatching. Nodes are ready for being processed
the next time.
marked with dark hatching. Nodes are already processed.
marked with arrows. Nodes whose events have been skipped, i. e.
events are missing in the trace.
marked with lightnings. Node where the erroneous event is detected.
In the upper left node of g. 6.2, the call{event is already processed and the
return{event is allowed in the current state. The upper right node has been processed completely. The return{event of the lower right node appeared erroneously
in the trace, so the call{event of this node was skipped (this error would be caused
by an instrumentation error).
If an error occurred, the subgraph which contains the error node appears in the
drawing canvas and the error node is displayed centered in the canvas. Otherwise
the drawing canvas remains unchanged.
6.3. RESULTS OF VALIDATION
Getting additional information for debugging purposes:
49
Pressing the right mouse button inside a node in the drawing canvas, the node's
parameters are displayed in a new window. This window contains the additional parameters Source line, Event number, Event time, and Occurrences. Values are
assigned to these parameters during the validation process. These values correspond
to the last event assigned to the selected node. The parameters have the following
meaning:
Source line:
It gives the source line of the procedure call represented by the
selected node. Using this information, the program's ow can
also be followed in the program's source text.
Event number:
Here the event record number of the last event assigned to the
selected node is indicated.
Event time:
This parameter contains the event time of the last event assigned
to the selected node.
Occurrences:
The number of occurrences of the event assigned to the selected
node is counted and shown in this parameter eld.
Note, as a node may be assigned two events, namely the entry and exit event of the
corresponding procedure call, the last three parameters of the above list can indicate
two values at a time separated by white space. Then the rst value corresponds to
the entry event and the second one to the exit event.
50
CHAPTER 6. CONSISTENCY VALIDATION
7 Trace Analysis
In this section, the model{driven creation of description les for trace analysis with
SIMPLE is described.
All tools of the evaluation environment SIMPLE (Source{related and Integrated
Multiprocessor and {computer Performance evaluation, modeLing, and visualization
Environment) [Moh91, Moh92] are implemented in a monitor and object system independent way. The necessary information about the syntax and semantics of the event
trace to be evaluated is taken from a so{called key le which can be obtained from an
event trace description in TDL (event trace description language). In a trace description
le (tdl{le) syntax and semantic of an event trace is described. The evaluation commands
for the tools, e.g. what should be evaluated, are taken from a so{called description le.
The commands in the description le depend on the user's aim and intention of the trace
analysis. But having knowledge about the event semantic (e.g. corresponding begin and
end events of activities) they can be created automatically or at least interactively by
selecting events and/or activities in the monitoring model.
Pressing the function Trace Analysis with the left mouse button, a new window with a
list of functions appears. With each function a description le for further use with a tool
of the evaluation environment SIMPLE can be created.
Based on the monitoring model, description les for calculating the mean runtime or the
runtime distribution of model activities (program TRCSTAT), displaying the monitored
event trace in Gantt charts (program GANTT), selecting events for further evaluation
(program FDLC), or for trace animation (program VISIMON) can be created.
In this version of PEPP, the automatic creation of description les for tools VISIMON,
TRCSTAT, and GANTT is implemented. Creating description les for the tool FDLC
will be implemented in the next version of PEPP.
7.1
Statistic:
Create a Description File for trcstat
This function is very useful for converting the (functional) monitoring model into a performance model. When the steps model creation, program instrumentation, monitoring,
and consistency validation are performed successfully, realistic performance parameters
like runtime distributions or branching probabilities can be obtained for the performance
model from the event trace. Therefore, the event trace analysis environment SIMPLE
provides the tool trcstat(1) (trace statistics) which allows to calculate essential values for
program analysis like frequency of events, distance in time between two occurrences of an
event, and duration of intervals dened by a start and an end event [Moh92].
The function Statistic can be invoked by clicking the left mouse button on the corresponding item of the Trace Analysis menu. A dialog window comes up where the
following parameters can be specied:
51
CHAPTER 7. TRACE ANALYSIS
52
Key File:
Trace File:
Statistic Description File:
This is the name of the key le for the event trace to be analyzed. The extension
.key is not necessary.
Name of the event trace le. The extension .trc can be omitted.
Species the name of the le in which the TRCSTAT description will be stored. The
sux .sdf will be appended automatically, if it is not already.
t2d File:
Time Resolution:
A t2d le (trace to density) is a UNIX shell script that generates numerical runtime
distributions (see section 8) from an event trace using TRCSTAT and CAPP (see
8.2.3.1). The created t2d le can be executed within a UNIX shell. It creates for each
node that fullls a few conditions (see below) a numerical density. The generated
numerical density will have the name of the corresponding node with the extension
.dis. If the desired densities are created, they can be assigned to the nodes with
the canvas function Change (see 3.1.2). However, a numerical density for a node can
only be created if the following conditions are fullled:
{ The node must have a node name.
{ In order to be able to calculate the duration of this node, there must be two
instrumentation points for this node which can be treated as start and end
events of the modelled program activity. A start event for a node may be
either its own entry point (g. 7.1,1) or the exit point of the node's predecessor
(g. 7.1,3), under the condition that there is no other predecessor. Similar,
the exit point can be used as an end event (g. 7.1,1) as good as the entry
point of a successor (g. 7.1,2), if the successor has only one predecessor. The
duration of a node which is not instrumented can be calculated if it has only
one predecessor which is instrumented at its exit point and if it has a successor
with the following two properties:
Its entry point has to be instrumented.
It does not have other predecessors than the node whose duration we want
to calculate (g. 7.1,4).
{ The above mentioned start events and end events must be dened in the event
trace description.
The time unit for the numerical densities can be specied here. There is a help
menu for this eld where you can select a time unit. It appears if you press an
arbitrary mouse button inside this eld. If you don't specify the time resolution,
the time unit given in the corresponding TDL description will be used. Time units
causing too small or too big values should be avoided, since this could lead to
numerical problems evaluating the model. The mean runtime of a node should be in
the interval [10?3 ; 103]. After assigning the calculated density to the corresponding
node, the mean runtime of this node can be checked with the canvas function Show
Density (see 3.1.8).
7.2.
GANTT:
CREATE A DESCRIPTION FILE FOR GANTT
instr E
e 1.5
instr E
e 1.5
pred E
e 1.5
pred E
e 1.5
instr E
e 1.5
instr E
e 1.5
succ E
e 1.5
(1)
(2)
53
succ E
e 1.5
(3)
(4)
Figure 7.1: Possible start and end events for a node
Statistic Mode:
Processor Dependent:
Here you can specify whether you want to calculate durations, distances, or frequencies. For the generation of numerical densities with a t2d le, the option Duration
must be activated with the left mouse button.
In this eld you are asked to calculcate numerical densities independent or dependent
from the processor on which the measured program activity is executed. If Yes is
selected, for each node which fullls the above conditions a set of numerical densities
will be generated by the t2d shell script. For each processor a separate density (.dis{
le) is calculated.
If you have nished the input of the parameters, you can start the generation of the le(s).
By clicking the left mouse button on Create, the sdf{le and, if specied, the t2d{le are
created. By clicking Cancel the function is left without any eect.
7.2
Gantt:
Create a Description File for gantt
The SIMPLE tool GANTT can be used to draw gantt charts of event traces. Gantt charts
are usually known as diagrams that represent the temporal evolution of dierent program
activities versus a common time axis [Moh92]. The trace analysis function gantt creates
a description le for the tool GANTT.
CHAPTER 7. TRACE ANALYSIS
54
To start this function you have to press the left mouse button on the gantt item of
the Trace Analysis menu. Then, a dialog window appears where you can specify the
following parameters:
Key File:
Trace File:
Gantt Description File:
Time Resolution:
Name of the key le for the event trace to be analyzed. The key le is necessary
for the monitor and object system independent access to the event trace and can
be created from an event trace description in TDL by the TDL{compiler tdlc(1)
[Moh92]. The extension .key can be omitted.
The name of the event trace le is required here. The extension .trc can be omitted,
too.
Here you have to specify the name of the GANTT description le that will be
created. If the given le name does not have the sux .gnt, it will be appended
automatically.
The resolution of the time axis for the gantt charts that will be created by the
SIMPLE tool GANTT can be specied here. If you press an arbitrary mouse button inside this eld, a selection menu appears where you can choose a time unit.
If no time resolution is specied, GANTT uses the time resolution given in the
corresponding TDL description.
If the rst three parameters do have the same name, you don't have to type the same
name three times. Insert the name (without extension!) at any of the three input elds.
The other le names are build automatically.
By clicking the left mouse button on Create, the generation of the gantt description
starts. If Cancel is clicked, the function is left without any eect.
The tool GANTT creates a gantt chart for each processor/process versus a common time
axis. You can change the set of processors/processes of a model with the canvas function
Mapping (see 3.1.7). Each diagram will have a activity for each instrumented entry point
of a node, so you can select the style of the gantt charts by changing the instrumentation.
However, there is a restriction. Instrumented entry points are only considered if they are
represented in the event trace description.
7.3
Visimon:
Create an Animation Description File
Using the function visimon, a description le for animating the monitored behavior with
VISIMON [Thi90] can automatically be created [Fre91]. After pressing the left mouse
button on visimon the main animation dialog window appears.
Parameters for the model{driven creation of an animation description must be entered.
The input elds of this dialog window are:
7.3.
VISIMON:
CREATE AN ANIMATION DESCRIPTION FILE
File:
55
Specify the le name where the animation description should be
stored (default: name of the actual model le appended by the
sux '.od', object description).
Window-size(x): Width of the animation window in screen pixels. The possible range
extends from 200 to 1024 pixels and can be changed in the resource
le Pepp (see section 9).
Window-size(y): Height of the animation window in screen pixels. The possible range
extends from 150 to 750 pixels and can be changed in the resource
le Pepp (see section 9).
Screen:
Graph
The animation description depends on the screen used for the animation with VISIMON. When pressing the button B/W, an animation description for running on a monochrome screen is created. If
an animation description for a color screen is desired the function
color must be selected.
:
Animation of the graph model. A second dialog window comes up
asking for further input (see below).
View
Processor View: Animation of processor view. A second dialog window comes up
asking for further input (see below).
Cancel:
The function animation is left without any eect.
Selecting Graph View the graph dialog subwindow comes up and oers the following
parameters to be selected:
Depth:
The number of hierarchy levels which are taken into account
for animation have to be specied. The number of windows is
determined as follows:
n = Number of rows * Subwindows per row
Depth
ranges from 1 to number of windows.
Subwindow Size[%]: Percentage of the animation window used to display subgraphs.
The possible range is 15 ? 75 and can be changed in the resource
le Pepp.
Number of
:
Number of rows or columns for the subwindows. The default
range is 0 ? 2. The upper limit can be changed in the resource
le Pepp.
Subwindows/row:
Number of subwindows in one row or column. The default range
is 0 ? 5. The upper limit can be changed in the resource le Pepp.
rows
CHAPTER 7. TRACE ANALYSIS
56
Layout:
Two possible layout modes are oered: HORIZONTAL MODE
and VERTICAL MODE. When selecting the HORIZONTAL
MODE, which is the default, the subwindows are placed horizontally at the lower border of the animation window. In case of
VERTICAL MODE the subwindows are placed vertically at the
right border of the animation window.
Animate:
Pressing this button, the animation description le for animation
of the graph model is created and the function animation is left
successfully.
Cancel:
The function Graph
Selecting the function Processor
taining the following input elds:
Processors:
Limit for
View
is left without any eect.
, the processor dialog subwindow is opened con-
View
If SPECIFIED in the eld Display is selected, a list of processors
have to be specied. Processor names in the list are separated by
a single apostrophe ('). To use an apostrophe in a name, double
it. The given string must not exceed 256 characters.
: If ALL in the eld Display is selected, the maximal number of
processors which may appear in an event trace has to be specied. It ranges from 1 to 32. The upper limit can be changed in
the resource le Pepp.
'ALL'
Columns:
Number of columns in which the processor objects will be positioned during animation. It ranges from 1 to 16. The upper limit
can be changed in the resource le Pepp.
Display:
Select display mode. If ALL is selected all processors will be
displayed in order of their occurrence in the event trace. If
SPECIFIED is chosen only the processors specied in the eld
Processors will be animated.
Dynamic Blocks:
Create animation description for dynamic block pictures (icons).
Dynamic Gantts:
Create animation description for dynamic Gantt charts (not yet
implemented).
Fill in:
The processor names used in the model are inserted into the
input eld Processors (not yet implemented).
Cancel :
The function is left without any eect.
7.3.
VISIMON:
CREATE AN ANIMATION DESCRIPTION FILE
57
7.3.1 Invocation of VISIMON
After creating an animation description the program VISIMON can be started. The program VISIMON is an X{Window application implemented with MIT{X11R4. It can be
invoked in the following way:
visimon
[
options ]
[
key le [ description le [ trace le [ index le ]
] ] ]
key le (default extension: .key) can be obtained from an event trace description in TDL
by using the TDL{Compiler tdlc. The description le (default extension: .OD) contains the
animation description. In trace le (default extension: .trc) an event trace representing
the dynamic behavior which should be animated is stored. index le (default extension:
.idx) is optionally used for accelerating the event trace access.
Valid options are:
Set time at which the animation should start. Time must be of the
form 'NumberTimeunit'. Number is a valid integer value. Timeunit
may be one of s, ms or us. If timeunit is omitted VISIMON uses ms.
-B event number Start the animation process at event record number event number
relative to the beginning of the event trace.
-d display
Specify the display where the animation should be displayed. display
must be of the form computer :display.screen. If the option is omitted,
VISIMON uses the environment variable DISPLAY. If the environment
variable is also missing, VISIMON terminates indicating the corresponding error.
-f font
Change the font for text output to font.
-gsize and position Set the size and the starting position of the VISIMON main menu.
Size and position have to be of the form widthxheight+x{coordinate+y{
coordinate. Note: This option is not valid for each window manager.
No default values are given.
-G size and position Set size and starting position of the VISIMON output window.
Size and position have to be of the form widthxheight+x{coordinate+y{
coordinate (default: 800x800+0+0).
-m buer size
Change buer size of the control window in the main menu to buffer size. Buer size may vary from 1 kByte to 100 kBytes (default: 10
kBytes).
-r retardation
Set retardation factor to retardation. This inuences the time spent
between two events in the event trace. The retardation factor must be
an integer number (default: 1).
-s time
Set time at which the graphical output of the animation should start
to time. In contrast to the option -b, every previous event in the trace
is processed completely, but not displayed.
-b
time
CHAPTER 7. TRACE ANALYSIS
58
-S
event number This option species an event record number relative to the beginning
of the event trace at which the graphical output of the animation
process should start.
This option forces VISIMON to produce messages on stdout.
The synchronization between the events and requests to be worked
up by the X{Server and the actual output of the graphic should be
neglected.
-v
-xs
Valid environment variables considered by VISIMON are:
KEYDIR
ODDIR
TRACEDIR
BMDIR
7.4
List of directories separated by colons (:) where key les should be
looked for.
List of directories separated by colons (:) where animation description
les should be looked for.
List of directories separated by colons (:) where event trace les should
be looked for.
List of directories separated by colons (:) where bitmaps les should
be looked for.
Filter:
Create a Description File for fdlc
This function is not yet implemented.
8 Model Evaluation
The program PEPP provides several evaluation methods which allow the prediction of
the mean runtime of a parallel program modeled by a stochastic graph. In the rst part
of this section we will take a short look at the dierent evaluation methods that are
integrated in PEPP. The second part of this section is the user's manual for the program
CAPP (Calculation And Presentation Package). This program is very useful for the
visualization of the results gained from some evaluation methods.
8.1 Available Evaluation Methods in PEPP
For the analysis of a model, the main menu function Evaluation must be activated rst
by clicking the left mouse button. Then, the menu EVALUATE GRAPH appears, from which
all the dierent evaluation methods can be selected by opening one of the submenus of
EVALUATE GRAPH (see g. 8.1).
PEPP provides three dierent evaluation methods: state space analyzing methods, SPASS
(Series PArallel Structures Solver), and bounding methods (see table below).
state space
analysis (SSA)
series-parallel-reduction
(SPASS)
graph
any
structure
runtime
any distr !
distribution de-approximation
function
series-parallel
approximate
mean runtime
runtime
distribution
results
(any)
numerical
distribution
non-series-parallel
(any)
numerical
distribution
lower/upper
bounds for the
mean runtime
In PEPP there are three kinds of state space analysis:
state space analysis
Before the evaluation starts, it is checked if the graph model is acyclic. First, hierarchical nodes in the graph are expanded and the subgraphs of loop nodes are
recursively analyzed and replaced by a deterministic node with the corresponding
mean value, so they can be handled like cyclic nodes. The evaluation is done in three
steps [Sot90]:
59
CHAPTER 8. MODEL EVALUATION
60
EVALUATE GRAPH
state space analysis ...
spass analysis ...
upper bound ...
lower bound ...
STATE SPACE ANALYSIS
state space analysis
SSA/upper bound
SSA/hierarchic
SPASS ANALYSIS
SPASS
SPASS stepwise
SPASS info
UPPER BOUND
best upper bound
Kleinoeder ...
Shogan
Dodin
Devroye
LOWER BOUND
best lower bound
Kleinoeder ...
Shogan
Devroye
Figure 8.1: The EVALUATE
GRAPH
KLEINOEDER
complete
stepwise
KLEINOEDER
complete
parallel step
serial step
menu and its submenus
8.1.1 State Space Analysis
{ The task runtime distribution of each node is approximated, depending on the
variance of the node, by one deterministically and one exponentially distributed
phase or by a two{phase hyperexponential distribution
{ Series reduction
{ The remaining graph, consisting of deterministically and/or exponentially distributed phases is analyzed by an approximate state space method
When the evaluation is nished, a window appears to display the results of the
evaluation. Four values are displayed in this window:
8.1. AVAILABLE EVALUATION METHODS IN PEPP
{
61
: number of nodes in the modied (reduced) graph which is used in the
state space analysis.
{ States: number of dierent states computed during the evaluation of the
state space.
{ Found: number of states which were reached more than once during computation.
{ Result: mean total runtime of the modeled program.
After an evaluation the result can be saved (using Save) or printed (using Print)
together with the graph model.
Nodes
SSA/upper bound
While the above described approximation of the mean runtime of hierarchical nodes
can be problematic, the approximation of the mean runtime of loop node subgraphs
does not have bad eects. Here, each subgraph of a loop node is replaced by an
exponentially distributed node instead of a deterministic node.
SSA/hierarchic
For small models the mean runtime can be computed very quickly with a state space
analysis. However, if the degree of parallelism is greater than 6, this method may fail
because of the state space explosion. In order to avoid this problem for hierarchical
graphs which can reach a high degree of parallelism after expanding, we decided to
implement the SSA/hierarchic{option. This method is very similar to the method
described above, but hierarchical nodes are analyzed separately. The mean runtime
of each subgraph is used as the parameter for a deterministically distributed node
which replaces the subgraph on the next level. The problem here is the approximation of the subgraphs runtime distribution by deterministic distributions. This can
lead to essential deviations of the nal result.
8.1.2 SPASS Analysis
Originally, the program package SPASS (Series PArallel Structures Solver) was an independent graph analysis tool for the evaluation of series-parallel graphs [Pin88]. Now, a
series-parallel reduction can directly be executed in PEPP. The submenu SPASS ANALYSIS
must be opened rst. This menu contains the following items:
SPASS
This evaluation method can be applied only to series{parallel reducible graphs
[Pin88]. This method delivers the numerical runtime distribution density, which
will be transmitted to the program CAPP.
SPASS stepwise
Only one step of graph reduction is done with this evaluation method. This allows
to show the stepwise series{parallel reduction of a graph model. It is also possible
to reduce a non series{parallel graph as far as possible to save time in a following
evaluation with another method. The graph can be restored with the Undo{function.
CHAPTER 8. MODEL EVALUATION
62
SPASS info
No evaluation, just displays the evaluation parameters IMAX , , and b used in numerical computations. These parameters cannot be changed by the user and must
be identical with the parameters used in the program CAPP.
8.1.3 Bounding Methods
If all the other methods fail, the only way to get any idea of the mean runtime is to
compute upper and lower bounds on the mean runtime. The program PEPP oers the
following methods:
Kleinoeder complete
This method computes the upper and lower bound by adding or removing arcs
[Kle82, HM92]. The results are displayed in a result window. If the program CAPP
is running, the results are transmitted to CAPP and displayed there, too.
Kleinoeder stepwise
The computation of upper bound is done stepwise. This allows to follow the modications applied to the model. It is possible to apply this method until a certain
point and then to continue the evaluation with other methods. The Undo{function
restores the old graph.
Kleinoeder parallel/serial step
The lower bound will be computed stepwise. There are two lower bounds of Kleinoeder which may deliver dierent results. Consider [HM92] for more details.
Shogan
This function computes the upper and lower bound using the method of Shogan
[Sho77]. The results are displayed in the result window and if the program CAPP
is running, the results will be displayed there, too. This method cannot be applied
to graphs with branching structures.
Dodin
The upper bound of Dodin is computed with this method [Dod85]. The result will
be displayed in the above mentioned result window. If CAPP is running, it will be
displayed there, too. This bound is especially useful for 'neighbor'{structures.
Devroye
The bounds of Devroye [Dev80] are computed and displayed in a result window.
Devroye delivers also an upper bound for the variance, but experience showed that
this is a very poor bound. Devroye does not support branching structures.
The functions best upper bound and best lower bound compute all upper respectively
lower bounds, except the bounds of Devroye. The best bound will be displayed. If the graph
is hierarchical, the bounds are computed recursively, i.e. for each subgraph all bounds are
computed and the best of them will be assigned to the corresponding hierarchical node.
All upper and lower bounds for a model are displayed together in one window and will
also be saved when the model is saved after evaluation. Besides the bounds on the mean
8.2. GRAPHICAL PRESENTATION OF RESULTS USING CAPP
63
runtime, the bound result window contains an upper bound for the variance. This bound
will be computed automatically if one upper bound and one lower bound are already
computed. Only the bounds of Devroye will not be considered, because his lower bound
is almost always the same as Shogans lower bound and the quality of the upper bound is
very poor in most cases. The new variance bound is clearly better than Devroyes bound,
but there can still be a big dierence between this bound and the exact variance.
Note: If SPASS analysis or any bounding method is executed while the actual graph on
the canvas is a subgraph of the main graph, only the actual subgraph will be evaluated.
8.2 Graphical Presentation of Results using CAPP
Series{parallel graphs can be evaluated numerically with PEPP. The result of such an
analysis is a numerical representation of the density of the mean runtime. The program
CAPP (Calculation And Presentation Package) allows to display numerical densities
graphically in a window. In the following sections the functions of CAPP are described.
For a detailed description of this program see [Mer91].
8.2.1 Invocation of CAPP
The program CAPP is | as PEPP | an X{windows application. It was implemented
with MIT{X11R4.
To start the program, just type
capp [ -m
monitoring le ]
[-d
density le ] [X{Options]
Options:
X{Options
-m
-d
All options dened for X{programs may be given (see X(1) for details).
monitoring le A le containing measured values will be loaded when starting
CAPP (see 8.2.3.1). If a density le is specied with the option -d,
CAPP converts the values into a numerical density, stores the result
in the specied density le for later use in PEPP, and terminates.
density le
If the option -m is not specied, the numerical density density le will
be loaded and displayed when starting CAPP.
For CAPP the resource le 'Capp' is used. All resource denitions of CAPP are
contained in this le. The system default resource le is kept in the directory
/usr/lib/X11/app-defaults. If a user wants to adapt the user interface of CAPP an
own resource le can be used.
CHAPTER 8. MODEL EVALUATION
64
8.2.2 Properties of CAPP
The main task of CAPP is to display the results of a numerical analysis done with PEPP.
To do this, the program PEPP sends the results of an analysis via the X{server to CAPP
using the X{server's properties mechanism. For visualization of numerical densities the
user must guarantee that CAPP is running when doing numerical analysis with PEPP.
Note: it is possible that CAPP and PEPP are running on dierent computers, the X{
server manages the connection between the two programs.
Further functions of CAPP are shown in the following list:
Create the numerical representation for standard distribution functions (e.g. expo
nential, branching Erlang distribution).
Combine two numerical representations (convolution, maximum, Shogan).
Save and load numerical representations.
Display of distribution functions and higher moments.
Computation of quantiles and distribution function values.
Print a density/distribution function.
Change the scale of the graphical display.
Create a numerical density from measured data. The created density can be saved
for later use with PEPP.
8.2.3 Usage of CAPP
The main menu of CAPP is shown in g. 8.2. To select a function from the main menu,
click on the corresponding item with the left mouse button. The function is executed (e.g.
display of a density) or a dialog window appears where further input is expected. Most
text input elds in dialog windows have a context sensitive help function which can be
activated by a mouse click inside the input eld.
Save
Load
Convolution Maximum
Convolution 2 Maximum 2
Print
Shogan
Shogan 2
Quit
Quantil
Moments
Distribution
Canvas Setup
F(t)
Figure 8.2: Main menu of the program CAPP
The following sections describe the available functions.
8.2. GRAPHICAL PRESENTATION OF RESULTS USING CAPP
8.2.3.1
65
Create the Numerical Representation of a Distribution
Distribution:
The function Distribution is used to compute the numerical representation of distributions. A selection list appears where a distribution can be selected.
: compute deterministic distribution.
deterministic
:
compute Erlang distribution.
erlang
: compute general Erlang distribution.
general erlangian
: compute a distribution consisting of one deterministically and one
exponentially distributed phase or a two-phase hyperexponential distribution.
approximate
: compute a numerical density from measured values for later use in
monitoring
PEPP.
: increase the order of the numerical representation.
increase order N
: redraw the last selected distribution.
last distribution
Parameters for the distribution are entered in a dialog window that appears after a selection has been done. The input of parameters can be guided by using the help function
which is activated by pressing the left mouse button inside the input eld. A short instruction informs which parameters are to be inserted and what ranges these parameters
can have. The parameters required for the rst four items must have the same format as
the probability parameters of a PEPP node (see 3.1.1.1).
By selecting Return the dialog window is closed. The representation for the selected
distribution is computed and displayed in the window. Cancel leaves the function without
doing any computation.
The runtime distribution of a node in a graph model can be determined from measured
data created by repeated measurements. A le with measured data values can be read in
using the function monitoring from the Distribution menu. The le name of the data
le must be specied in the dialog window. A numerical representation is computed by
CAPP from the values read in. The data le is an ASCII text le containing the values
separated by spaces or carriage returns:
t1 t2 t3 : : : tn
where ti are the measured values and n is the number of values.
8.2.3.2
Load, Save:
Load and Save a Numerical Representation
To save or load a numerical representation to/from a le the functions Save and Load
are used. A dialog window appears where the le name can be specied.
CHAPTER 8. MODEL EVALUATION
66
8.2.3.3
F(t):
Display Distribution Function
Two dierent modes for the display of numerical representations can be selected by F(t):
: display densities (F(t) normally displayed).
Density-mode
: display distribution functions (the button F(t) is displayed
Distribution-mode
in reverse video).
Clicking on F(t) toggles the mode.
8.2.3.4 Combination of two Numerical Representations
To combine two numerical representations three operators can be used: Max, Conv and
Shogan. The rst operator computes the maximum of two distributions. The Conv{
operator computes the convolution of two densities and the Shogan{operator computes
the Shogan{minimum of two distributions (see [Kle82]). Every operator has two forms:
the rst form (Max, Conv, Shogan) combines the actual representation with itself and the
second form (Max2, Conv2, Shogan2) combines the actual representation with the last
representation created.
8.2.3.5
Print a Distribution/Density
Print:
A distribution function or a density can be printed with the function Print. A dialog
window containing the following elds appears.
: Name of the output le to create.
Print file
: Title used in the output.
Title
: Subtitle used in the output.
Subtitle
: Scale factor for the output.
Scale
: Select the output device. Default is ps which creates a PostScript le.
The other devices are for special laser printers, see the X{windows manual of the
command xpr for a further explanation.
Device
Print mode: Select output format landscape or portrait.
OK: Create the selected output le which can be sent to a laser printer.
Cancel: Leave the print function without creating an output le.
8.2. GRAPHICAL PRESENTATION OF RESULTS USING CAPP
8.2.3.6
67
Computation of Quantiles and Distribution Function{Values
Quantil:
The function Quantil is used to compute a quantile or a function-value of the actual
distribution. In a dialog window the probability p for a quantile and/or the time t for a
function{value can be entered. Using OK the quantile and the distribution function value
are computed and appear in a result window.
8.2.3.7
Computation of Higher Moments
Moments:
When the function Moments is selected, the higher moments for the actual distribution are
computed. A parameter window displays the computed values. The window disappears
by pressing OK.
8.2.3.8
Canvas Setup:
Change of Scale
Normally the graphical display is scaled automatically. Using the function Canvas
it is possible to set up manually the borders for the graphical display.
Setup
: Select upper border for the density. The lower border is always set
Upper border
to 0.
: Select minimum value for t.
Right border: Select maximum value for t.
Manual setup : Turn on manual scaling (ON) or return to automatic scaling
(OFF).
OK: Changes scale as specied above.
Cancel: Leave setup function without any change.
Left border
8.2.3.9
Quit:
Leave the Program CAPP
With the function Quit the program CAPP can be left. The function Show density in
PEPP has no eects. Results calculated by PEPP will not be displayed any longer.
68
CHAPTER 8. MODEL EVALUATION
9 Customizing PEPP
To keep the interface of PEPP user{friendly and easily changeable, a resource directory
is used where les containing information concerning the interaction between PEPP and
the user are located. The name of the resource directory can be set by the environment
variable XAPPLRESDIR using the Unix SHELL command set or the Unix C{SHELL command setenv. If the environment variable XAPPLRESDIR is set, both resource les (Pepp
and Capp) must be stored in the given directory.
The les stored in the resource directory are the following:
:
Here the icon bitmap for CAPP is stored.
capp.messages: Contains the warning and error messages that are being popped up
when an error occurs.
Capp:
This le contains all information about the layout of the user interface
of CAPP, for example the geometry and color of the main window and
all popup menus, the text font size, the names of the buttons.
pepp.xbm:
Here the icon bitmap for PEPP is stored.
pepp.messages: If an error occurs during the work with PEPP, error messages are
popped up. This error messages are dened in the le pepp.messages.
Pepp:
This le contains all information about the layout of the user interface
of PEPP, for example the geometry and color of the main window and
all popup menus, the text font size, the layout of the menu lines,
especially the names of the buttons.
pepp man.dvi: Manual for PEPP and CAPP stored as a dvi{le. This is used for the
main menu function Manual in PEPP.
capp.xbm
When desired, the user is able to create his own resource directory. Then the interface
of PEPP and CAPP can be designed according to the fancy of each user by editing the
corresponding entry in one of the les.
69
70
CHAPTER 9. CUSTOMIZING PEPP
Bibliography
[Ber88]
J. Bergmann. Instrumentation of Communication Software (in German). Master's thesis, University of Erlangen{Nurnberg, IMMD VII, 1988.
[Dau93]
P. Dauphin. Improvements of the SIMPLE tools' User Interface. Technical
Report in preparation, University of Erlangen, IMMD VII, August 1993.
[Dau94]
P. Dauphin. Combining Functional and Performance Debugging of Parallel
and Distributed Systems based on Model-driven Monitoring. submitted to:
EUROMICRO Workshop on \Parallel and Distributed Processing", University
of Malaga, Spain. In , 1994.
[Dev80]
L.P. Devroye. Inequalities for the Completion Times of Stochastic PERT
Networks. Math. Oper. Res., 4:441{447, 1980.
[DHK+92] P. Dauphin, R. Hofmann, R. Klar, B. Mohr, A. Quick, M. Siegle, and F. Sotz.
ZM4/SIMPLE: a General Approach to Performance{Measurement and {
Evaluation of Distributed Systems. In T.L. Casavant and M. Singhal, editors,
Advances in Distributed Computing: Concepts and Design. IEEE Computer
Society Press, 1992.
[DKQ92] P. Dauphin, M. Kienow, and A. Quick. Model-driven Validation of Parallel
Programs Based on Event Traces. In Proceedings of the Conf. on Programming
Environments for Parallel Computing, 1992.
[Dod85]
B. Dodin. Bounding the Project Completion Time Distributions in PERT
Networks. Operations Research, 33(4):862{881, 1985.
[Fre91]
H. Freund. Model{driven Animation of Dynamic Behavior (in German). Master's thesis, University of Erlangen{Nurnberg, IMMD VII, 1991.
[HKM+92] R. Hofmann, R. Klar, B. Mohr, A. Quick, and M. Siegle. Distributed Performance Monitoring: Methods, Tools, and Applications. Technical Report
8/92, Universitat Erlangen{Nurnberg, IMMD VII, August 1992. submitted
to IEEE Transactions on Parallel and Distributed Systems.
[HM92]
F. Hartleb and V. Mertsiotakis. Bounds for the Mean Runtime of Parallel
Programs. In J. Hillston and R. Pooley, editors, Sixth International Conference
on Modelling Techniques and Tools for Computer Performance Evaluation,
1992.
71
72
[Kie90]
[Kie91]
[Kle82]
[KQS92]
[Mer91]
[Mil90]
[Moh91]
[Moh92]
[Pin88]
[Sho77]
[Som90]
[Sot90]
[Thi90]
BIBLIOGRAPHY
M. Kienow. A Graphical User Interface for the Graph Analysis Program
PEPP (in German). Internal study, University of Erlangen{Nurnberg, IMMD
VII, 1990.
M. Kienow. Automatic, Model{driven Validation of Event Traces (in German). Master's thesis, University of Erlangen{Nurnberg, IMMD VII, 1991.
W. Kleinoder. Stochastic Analysis of Parallel Programs for Hierarchical
Multiprocessor Systems (in German). PhD thesis, University of Erlangen{
Nurnberg, 1982.
R. Klar, A. Quick, and F. Sotz. Tools for a Model{driven Instrumentation
for Monitoring. In G. Balbo, editor, Proceedings of the 5th International
Conference on Modelling Techniques and Tools for Computer Performance
Evaluation, pages 165{180. Elsevier Science Publisher B.V., 1992.
V. Mertsiotakis. Extension of the Graph Analysis Tool SPASS and Integration into the X-Window Environment of PEPP (in German). Internal study,
University of Erlangen{Nurnberg, IMMD VII, 1991.
O. Milhim. Automatic Instrumentation of C{Programs and Generation of the
Corresponding TDL{Description (in German). Master's thesis, University of
Erlangen{Nurnberg, IMMD VII, 1990.
B. Mohr. SIMPLE: a Performance Evaluation Tool Environment for Parallel
and Distributed Systems. In A. Bode, editor, Distributed Memory Computing,
2nd European Conference, EDMCC2, pages 80{89, Munich, Germany, April
1991. Springer, Berlin, LNCS 487.
B. Mohr. SIMPLE | User's Guide Version 5.3.
Part A: TDL Reference Guide
Part B: POET Reference Manual
Part C: Tools Reference Manual
Part D: FDL / VARUS Reference Guide. Technical Report 3/92, University
of Erlangen{Nurnberg, IMMD VII, March 1992.
H. Pingel. Stochastic Analysis of Seriesparallel Programs (in German). Internal study, University of Erlangen{Nurnberg, 1988.
A.W. Shogan. Bounding Distributions for a Stochastic PERT Network. Networks, 7:359{381, 1977.
W. Sommer. Approximative Analysis of non Seriesparallel Graphs (in German). Internal study, University of Erlangen{Nurnberg, IMMD VII, 1990.
F. Sotz. A Method for Performance Prediction of Parallel Programs. In
H. Burkhart, editor, CONPAR 90{VAPP IV, Joint International Conference
on Vector and Parallel Processing. Proceedings, pages 98{107, Zurich, Switzerland, September 1990. Springer{Verlag, Berlin, LNCS 457.
T. Thiel. A Graphical User Interface for a Visualization System (in German).
Internal study, University of Erlangen{Nurnberg, IMMD IV, 1990.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising