DYANA - THE SYSTEM FOR DISTRIBUTED PROGRAMS AND COMPUTER SYSTEMS BEHAVIOR ANALYSIS A.G. BAKHMUROV, R.L. SMELIANSKY
Computer Systems Laboratory, Computer Mathematics and Cybernetics Department, Moscow State University, Leninsky Hills, Moscow, 119899, Russia. e-mail:
[email protected]
ABSTRACT
The tool for distributed computer environment simulation and analysis is described. Within the DYANA environment, both quantitative and algorithmic analysis of system to be modeled are possible. A unique model description is used for each type of analysis. The execution time estimation of the modeled program can be done without the instruction-level simulation of target computer system. The DYANA architecture and the model development language overview is presented. Keywords:
Performance analysis, distributed computer systems, simulation, temporal logic
1. Introduction
The DYANA system (DYnamic ANAlyzer) is the software system which is intended to analyze distributed computer environment operation. The design and development of the system were aimed at the following: to develop the tool for describing software behavior for distributed systems as well as hardware of such systems; to develop the tool for systems performance estimation under the di erent tradeo s between hardware and software on the project system level stage; to perform the quantitative estimation of system performance characteristics, such as execution time, queue length, CPU utilization etc.; to do the logical analysis of certain properties of program behavior, such as liveness, safety, deadlocks, livelocks etc.; to use a unique description of a modeled system as for algorithmic as as for quantitative methods of analysis mentioned above; to test the approach to the development of the distributed systems simulation model with variable degree of detalization; to experiment with a simulation models of software and hardware independently; to develop and to debug a distributed program through its model. Problems we needed to solve: how to nd a unique way to describe the program behavior; how to cover such particularities of the modeled object, like indeterminism of program behavior, absence of a unique time in the considered systems, existence of two types of parallelism (interleaving and real concurrency); how to develop the Computational Work Measure for the purpose of execution time estimation of sequential piece of C code for di erent computer architectures;
how to make not separated tools but integrated environment. Our model development technology: supports "top-down" model development methodology; separates the description of object interface from its implementation (e.g. localizes the changes in the model text etc); visualizes the behavior of the objects; keeps close the syntaxes of model description and speci cation languages. The theoretical issues of our approach could be found in [5,6,7]. Our concept of combined approach to distributed system analysis is explained brie y In the Section 2, Sections 3-8 pay attention to DYANA subsystems including language issues, the problems of algorithmic analysis, and model development technology.
2. The Combined Approach Concept
Neither a single algorithmic analysis of the distributed systems nor a single quantitative analysis is complete because of some particularities of their behavior. We de ne these kinds of analysis through the di erences of the methods that they use. The quantitative analysis uses the method of queueing theory, of the operational research theories etc. The main feature of these methods is that time is used as a metric value there. The algorithmic analysis uses the methods of automata theory, the algorithmic theory (like Petri Net, Turing Machine, Markovian Algorithms etc.). The main feature of the algorithmic analysis methods is that time is not a metric value. Time has a form of events ordering there. Each of the enumerated types of analysis uses its own form of the model description. Consequently, the user has to transform the model description from one form in another. There are no guaranties that the model descriptions before and after these transformations are adequate. Also, there are no formal methods to ascertain the di erences between these forms of the same model. As a result, this transformation is a source of errors. The main idea of the combined approach [1,2] is to develop such form of the model description which can be automatically transformed as for quantitative as for algorithmic analyses. None of the existing simulation modeling system do that. The architecture of the DYANA system is shown on the Fig. 1. In the sections below, the system components are described.
3. Model Description Language (MC-SIM)
The model description of distributed computer system consists of a distributed executor description (model of hardware), distributed program description (model of system software (like operating system etc.) and applied programs behavior) and a binding description (programs allocation to executors). For more formal de nition of these notions see [6]. A distributed program (or DP for brevity further) is constructed from sequential processes and distributed programs. Sequential processes interact with each other with sending/receiving messages via bu ers. An input bu er is used for storing messages under certain queuing discipline (FIFO queue, stack, priority queue, nondeterministic selection). An output bu er is just an identi er for connection with one of input bu ers. A distributed executor (or DE for brevity below) is constructed from sequential executors and other distributed executors. A sequential executor has a description of its architecture, where some its characteristics like instruction set, memory and register structure etc. are provided.
I n t e g r a t e d D e v e l o p m e n t E n v i r o m e n
Model description language compiler (program behavior &
Architecture description subsystem (hardware description)
Database
Time complexity estimation subsystem
Version control
Runtime subsystem
Visualization subsystem
Specification subsystem
t
Figure 1: Architecture of the DYANA system A binding describes a mapping of the sequential processes to sequential executors, and also de nes mapping of the interprogram logical links on the channels of the executors. Description of a sequential process consists of head and body. The head speci es the interface characteristics | name of the process and names of its external bu ers. A body is a description of an algorithm of process operation. A body description is invisible for other model components, e.g. for a distributed program, where this process is placed. This partition of a process description provides the locality of corrections: modi cations of a process body cause no modi cations and recompilations of the other parts of the model. For example, a sequential process body can be replaced with certain distributed program. The syntax of programming language C is the basis of process description language. It allows to adopt from C many well-known data types, operators and statements. 3.1. Timing Statements The timing statements allow to de ne the time duration of internal activity of modeled objects, i.e. activity, which require no interaction with environment. There are two statements for this purpose | delay and complex. Delay statement sets the duration explicitly as a number. With complex statement user may set the duration with describing a sequential fragment of computation in the C language. This fragment is executed during the model run. The execution time of such a fragment on a target computer is calculated using the information about technical characteristics of executors. For more details, see Section 5 below. We must notice that using complex statements it is possible to obtain a results of modeled program execution together with its performance characteristcs.
3.2. The Distributed Program The distributed program (DP) description consists of head (interface) and of its structure description, which includes:
(a) list of subcomponents (that is, processes and other distributed programs); (b) description of the links between subcomponents; (c) de nition of external inputs and outputs of whole DP. This partition on interface and internal structure is aimed again to provide ability of models building up and to support of the development complex, but easily recon gurable models. 3.3. Programs and Executors. Binding the Program to Executor The program itself is a pure logical entity. It does not contains "time". The time appears when the program is bound to the hardware. An abstraction of hardware component, the executor concept is an important distinctivefeature of the MC-SIM language. An executor represents the hardware of the modeled system and maps the complexity of program's internal actions to modeling time. There are sequential executors (SE) and distributed executors (DE). The latter are being constructed from SE's and previously constructed DE's, just like distributed programs. The SE is an abstraction of a sequential equipment which can perform only one action at a time. For SEs certain technical performance characteristics could be speci ed, such as the modeling time scale for this executor, the modeling time needed to start the sending and receiving of a message. It is possible to specify the architecture of an executor (see Section 5). The structure of the DE description is similar to one of DP's. As a part of a DE description it is possible to specify links (channels) between executors forming the DE. The so-called binding descriptions are intended to specify the allocation of processes on executors.
4. The Runtime Subsystem. Execution in Modeling Time
Before execution, the program description is translated to the text in C language, compiled and linked with the DYANA runtime library. To reproduce and to observe the program behavior correctly, the methodology of simulation is used. Having the description of executors and binding in the model it is possible to map the actions of the process onto the modeling time. (By action we mean interval activity of a process speci ed by complex or delay statement as far as sending or receiving of messages). Every SE has its own time axis (with the scale ts given in timescale declarator). An internal activity with duration t is mapping to the time axis with duration t ts. The executor's clock synchronization takes place in moments of receiving messages. Processes allocated to distinct executors run concurrently in modeling time (if these processes don't wait for each other). Processes allocated to the same SE run in interleaved fashion. Hence introduced notions of executors and of binding allow to simulate both kinds of parallelism | real concurrency and interleaving. The binding description can easily be altered without changing program as well as executor description. This feature of MC-SIM language simpli es investigation how a process-to-executor allocation a ects the program performance as well as the program tuning for given computer system structure.
5. The Timing Estimation Subsystem. Architecture Description
To estimate an execution time of a text fragment in C language in the complex statements the special subsystem of the MC-SIM compiler was designed and implemented. The underlying theory and architecture of this subsystem were described in [3,4,7]. Brie y, the main idea is as follows. A model of sequential computer was constructed, with parameters that are essential for optimal code generation. For this model, the optimal code generation algorithm was implemented. The execution time estimate is computed by the length of code generated. During testing, the relative error of execution time prediction was in range of four to ten percents which is acceptable for practical use. The architecture description itself is placed separately from the executor's ones and speci es the clock rate, register structure and instruction set of an executor. To simplify the process of architecture description, a special subsystem is under development. This subsystem will provide graphical description of disctributed executor structure along with the tabular form of sequential executor architecture description.
6. The Visualization Subsystem
During the model run, an event trace is recorded. Events are associated with interprocess communication and with the beginning and nishing of process internal actions. The collected trace could be viewed in the form of timing diagram, like in, for example, in the Flushot project [8]. User can do the following on the diagram: to scroll the diagram left and right, up and down; to change the scale of model time axis on the diagram; to select the model components of interest for visualization; to get an additional information about event and state attributes by clicking on event (state). An important feature of our visualization tool is the capability of component's states calculation and generation of some higher level events from ones recorded for processes. The examples are: events for executors; events for distributed programs (consisting of a number of processes); In addition, a user will soon be able to locate the corresponding piece of process's text while browsing events.
7. The Speci cation and Algorithmic Analysis Subsystem
The Algorithmic analysis subsystem is a subsystem that allows a user to specify and to check algorithmic properties of a distributed system, written in MC-SIM language, and to verify the speci cation itself. The common feature of the algorithmic properties is that time is not a metric value but a form of event ordering. These properties apply to a whole behavior of a system (not to one or nite number of traces of the system). In this system, all the properties describable in branching time logic, can be speci ed and checked. The main tool of the Algorithmic analysis subsystem is MC-SPEC | a speci cation language, by means of which a user can specify algorithmic properties of processes, bu ers and the whole system. The MC-SPEC language is syntactically familiar with the MC-SIM language in that a user works with the same notions and objects, that are used in MC-SIM. The properties of processes are speci ed and checked separately from the properties of bu ers and the whole system. This is done for the sake of eciency, because in the description of the system behavior we distinguish macrostates of each process (so called process' steps), while in the description of the process behavior we can a ord to
Model source texts
Processes source texts
Specification
Processes behavior
Processes binding description
System behavior
checking that the specification holds
Processes behavior specification
Verification of the specification
checking that the specification holds
System & buffers behavior specification
Figure 2: The architecture of the Speci cation Subsystem de ne it's state as the collection of values of all it's variables. But, on the other hand, this allows the user to focus only on the properties he is interested in without making detailed speci cation of each process. The algorithmic analysis subsystem works as follows (See Fig. 2). First, it converts the source texts of each process into the special form, that we call "process behavior graph". Then, using these behavior representations and the information about binding of processes' bu ers, the subsystem evaluates the "system behavior graph", that is a representation of all possible transitions between system states. Having done this, the subsystem converts the expressions in MC-SPEC language into the special form, that is close to a formula in the language of branching time temporal logic. This formula is then checked for being equal false, and if it is, the speci cation is incorrect. Then the subsystem checks that the speci cation holds for the processes and system behavior. If it doesn't hold, then the detailed information about the parts of the speci cation that caused the incorrectness, is printed.
8. The Integrated Development Environment 8.1. The Technology of Model Development During the development of the MC-SIM language special attention was focused on support of top-down design technology which allows a user to start from the large-grain model picking up only general structure of system to be simulated and ignoring small-
grain details. Gradually, step-by-step small details are re ned, more and more detailed models are developed. Such an stepwise detail should be performed in three directions. (a) Structure detail implies the detail of component's internal structure (e.g. replacing the message sending by certain processing of the message). Such a feature is provided by independence of the distributed programs and the executors description on internal structure of embedded subcomponents. Because of modularity, changes in any part of the model does not require changing (and even recompiling) of other parts. (b) Action detail (i.e. move from simple prototyping of a process interface to real data processing). This kind of detail is provided by two ways to time complexity speci cation | the delay statement (it sets the model time delay explicitly but specify no computations) and the complex statement (it speci es computations, and model time delay is estimated by the special subsystem). (c) Message type and structure detail (i.e., for example, going from checking message type only to analysis of message contents). To support such a detail, there exist two families of operators on msg-variables | the former use message type only, the latter group provide an access to message elds. 8.2. IDE Features For increasing of eciency of model building a special language-oriented instrumental environment was developed. This language-oriented environment relieves the user from necessity of working with les. The text of model description is split to components matching parts forming the model description (i.e. external interface description, process implementation, executor's internal structure etc.). Every component has a prototype which speci es its interface and a set of implementations representing di erent versions of the component's body. These components are stored in the database along with the results of intermediate processing. The main advantages of such an environment are as follows: (a) From the user's viewpoint, the text representation ts in the meaning structure of this text, which keeps the user away from care of text storing. (b) The usage of database provides the correspondence of external representation (e.g. screen images) of the set of descriptions with their internal organization (e.g. storing the representation of descriptions in the database). (c) The technology of model compiling and assembling becomes improved since: compiler has an access to descriptions of all components; all intermediate results are stored in the database; the semantical and time dependencies between source text components could be watched more accurately, which reduce the overheads during assembling compiled model. We should highlight an important feature of developed environment | the interface description of a component can be combined with more than one version of component implementation, the implementations may be either sequential or distributed. This feature lets: (a) to perform the stepwise detail, with possibility to get back to earlier stages of development at any time;
(b) to experiment with di erent con gurations of developed and debugged model (e.g. with di erent versions of components implementations), what is the nal goal of the user of simulation system.
9. Conclusion
For our point of view, the most interesting features of the DYANA system are as follows: the duality of analysis methods; the time complexity estimation which helps to avoid the target architecture emulation. the possibility of precise reproduction of distributed program behavior for messagepassing architectures without having the parallel machine itself. Now the prototype system is implemented in the MS-DOS environment and is partly ported to the SunOS environment. The nearest goals of future work are: to spread the database approach onto trace storage and processing; to implement the algorithmic analysis subsystem; to extend the capabilities of time complexity estimation to some classes of pipelined and array processors; to enable the description of interrupts, priorities and client-server communications in the model description language.
References 1. R.L. Smeliansky, The combined approach to the parallel system operation, Programming, 3(1988) (in Russian). 2. R.L. Smeliansky, Yu.P. Kazakov, Yu.V. Bakalov, The combined approach to the distributed computer system simulation, in Proc Conference on Parallel Computing Technologies, Novosibirsk, Scienti c Centre, Sept. 1991. 3. A.P. Kapitonova, I.A. Terehov, R.L. Smeliansky, The instrumental system for estimation of computational complexity in programs, MSU Press, Moscow 1991 (in Russian). 4. A.P. Kapitonova, I.A. Terehov, R.L. Smeliansky, On the computational work measure, in Software and methods for making decisions(MSU Press, Moscow, 1989) (in Russian). 5. R.L. Smeliansky, Program behavior invariant as the basis for system performance estimation, in Proc Conference on Parallel Computing Technologies, Obninsk, Russia, Sept. 1993. 6. R.L. Smeliansky, Distributed computer system operation model, Moscow University Computational Mathematics and Cybernetics, 3(1990), p. 4-16. 7. R.L. Smeliansky, The distributed computer systems performance estimation on the basis of program behavior invariant, Thesis of Doctoral Dissertation, Moscow State Univ. (1990) (in Russian). 8. V. Herrarte, E. Lusk, Studying Parallel Program Behavior With Upshot. Tech. Rep. of Argonne National Laboratory ANL{91/15, August 1991.
