by ezequiel glinsky research assistant, university of buenos aires, argentina

by Ezequiel GlinskyResearch Assistant, University of Buenos Aires, Argentina

Supervisor: Prof. Gabriel A. WainerSCE, Carleton University

Thursday, November 15th, 2001ESG Seminars

Overhead analysis of Overhead analysis of Discrete Event models executionDiscrete Event models execution

Seminar topics will include...Seminar topics will include...

Introduction to DEVS formalismPerformance analysis of different

DEVS toolsRT-DEVS extension to the formalismDevelopment of enhancements

(work-in-progress)

• DEVS = Discrete Event System Specification

• Provides sound formal M&S framework

• Supports full range of dynamic system representation capability

• Supports hierarchical, modular model development

(Zeigler, 1976/84/90/00)

DEVS Modeling & Simulation Framework (Introduction)DEVS Modeling & Simulation Framework (Introduction)

Discrete-Event formalism: time advances using a continuous time base.

Basic models that can be coupled to build complex simulations.

Abstract simulation mechanism

Atomic Models:

M = < X, S, Y, int, ext, , D >.

Coupled Models:

CM = < X, Y, D, {Mi}, {Ii}, {Zij}, select >

Sample model

DEVS Modeling & Simulation Framework (contd.)DEVS Modeling & Simulation Framework (contd.)

Testing & Performance AnalysisTesting & Performance Analysis“Performance analysis of different DEVS environments”

We need a synthetic model generator to represent different possible model

configurations

Why do we need a Model Generator? Detect bottlenecks

Characterize tool’s overhead Test automatically and thoroughly

Appreciate current overhead and therefore consider the possibility of RT simulation execution

A model generator (contd.)A model generator (contd.)

Available parameters: Depth Width Dhrystone code in transition functions Model type



Number of levels of the modeling hierarchy.



Number of children belonging to each intermediate coupled component.



Allows us to execute time-consuming code inside both the internal and external transition functions.



Different types of models can be generated, with different behavior, coupling and interconnections.


Sample model

ParametersDEPTH = 4WIDTH = 3Time in Internal Transition = 50 msTime in External Transition = 50 msModel Type = 1 (coupled component #1 and #2 are not shown)

Testing & Performance AnalysisTesting & Performance Analysis

Available environments:

Original CD++ simulator Parallel CD++ with NoTime kernel Parallel CD++ with TimeWarp kernel Real-Time CD++




Only provides stand-alone simulation.Doesn’t need to relay on any intermediate layer.




Uses a middle-ware to allow parallel simulation.NoTime: Unsynchronized kernel




Uses a middle-ware to allow parallel simulation.TimeWarp: Optimistic approach


Obtained Results

X-Axis: Executed simulationY-Axis: Total execution time

0

500

1000

1500

2000

2500

3000

E F G H

Tim

e (m

s) Original CD++Parallel NoTimeParallel Warped

0

50000

100000

150000

200000

250000

300000

350000

400000

A B C D

Tim

e (m

s) Original CD++Parallel NoTimeParallel WarpedTheoretical

All obtained results have been acquired using centralized model execution.

Difference between theoretical and executed simulations

0

500

1000

1500

2000

2500

3000

A B C D

Simulation

Difference (time in ms)

Original CD++Parallel NoTimeParallel Warped

Overhead (%)

0.00%0.20%0.40%0.60%0.80%1.00%1.20%1.40%

A B C D

Simulation

% o

f ove

rhea

dOriginal CD++

Parallel NoTime

Parallel Warped

Testing & Performance AnalysisTesting & Performance AnalysisConclusions:

Original CD ++ executes with minimum overhead on stand-alone simulation

Each technique induces a different overhead to the simulation that remains stable under normal conditions

Whenever parallel execution is needed, NoTime kernel outperforms TimeWarp kernel

To analyze distributed performance, testing should be done on a distributed RT simulations.

Real-time DEVS (RT-DEVS)Real-time DEVS (RT-DEVS)

What is RT-DEVS? RT-DEVS is an extension to the DEVS formalism

Why do we need RTDEVS? To run models interacting in a real-time environment To study real-time performance with the designed

models

RT-DEVS (contd.)RT-DEVS (contd.)Main differences between usual approach and RT-DEVS

Time advance is linked to the wall-clock all along the simulation.

Timing constraints are checked against the wall-clock on some given checkpoints

Time is not linked to a clock at all. Instead, virtual time is used (logical clock).

No timing constraints

Usual approach RT-DEVS

RT-DEVS (contd.)RT-DEVS (contd.)

What do we measure when executing RTDEVS? Why?

Worst-case response time # of missed deadlines

Besides...– log provides detailed information about the message

passing– output results show most important timing information briefly:

(wall-clock time, deadline, port, output value)

RT-DEVS - Sample ModelRT-DEVS - Sample Model

Alarm Clock Simple timed-model design,

no modification required to run under RT-DEVS

Timing performance can be easily validated

Can be seen as a component of a time-critical system– Flight-control systems– Industrial plants– Complex high-speed

communications & systems

Designed by Christian JacquesSCE, Carleton University

Testing Real-Time performanceTesting Real-Time performance

A new tool is needed: an event generator

Testing technique: Different model types, sizes and time-consuming transitions Different frequencies and associated deadlines

Goal: Obtain a detailed characterization of the tool’s overhead Performance analysis

Parameters: time between events, associated deadline

Testing Real-Time performance (contd.)Testing Real-Time performance (contd.)

Worst-case execution time - Obtained results (1)

0

1000

2000

3000

4000

5000

6000

7000

3 6 9 12

Depth

Tim

e (m

s) Theoreticaltime

Execution time

Model type = 1Width = 12 Internal transition = 50 ms External transition = 50 ms

Y-Axis: worst-case time (ms)X-Axis: model’s depth


Worst-case execution time - Obtained results (2)

Y-Axis: Difference between theoretical and actual execution timesX-Axis: model’s depth

20

70

110

160

0

20

40

60

80

100

120

140

160

180

3 6 9 12

Depth

Tim

e (m

s)

Difference

0

0.5

1

1.5

2

2.5

3

3 6 9 12

DepthTi

me

(ms)

% Overhead

Y-Axis: % of overhead incurred by the RT simulatorX-Axis: model’s depth


Missed deadlines - Obtained results (1)Width = 10Depth = 10Internal Function = 50 msExternal Function = 50 msNumber of events = 100Time between events = 8200 msTheoretical Execution Time = 8200 ms

Y-Axis: % of successX-Axis: Associated deadlines

% Success in Real-Time DEVS

0.00%20.00%40.00%60.00%80.00%

100.00%

5 * T

heor

etica

l

4 * T

heor

etica

l

3 * T

heor

etica

l

2 * T

heor

etica

l

1 * T

heor

etica

l

Associated deadlines

% o

f Suc

cess

% Success


Missed deadlines - Obtained results (2)Width = 10Depth = 10Internal Function = 50 msExternal Function = 50 msNumber of events = 100Associated deadline = 2 * Theoretical execution timeTheoretical Execution Time = 8200 ms

Y-Axis: % of successX-Axis: Time between events

% Success in Real-Time DEVS

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

20000 10000 8200 5000 1000

Time between events (ms)

% o

f Suc

cess

% Success


Conclusions

Increasing complexity Increasing response times Nevertheless, percentages of overhead remains nearly stable

simulations can be carried out properly

Bottom line: After thorough testing, we can say the real-time simulator is able to execute simulations properly even under difficult conditions (high workload and mid to large-scale models)

Flattened SimulatorFlattened Simulator

Why do we need a flattened simulator?

To increase tool’s performance and simulate successfully even more

complex models with higher workload

(Work-in-progress)


Associated hierarchical simulator

Model hierarchy

Existing hierarchical simulator:

Intermediate coordinators associated to each coupled component

High number of messages exchanged along the simulation

This induces more overhead!


Proposed flattened simulator:

Must keep separation between model and actual simulator

Reduce number of intermediate coordinators

Simplify hierarchy and reduced message exchange along the simulation

Less overhead expected!


Non-hierarchical flattened simulator

Hierarchical simulator

Existing hierarchical simulator Proposed flattened simulator

Only one coordinator exist, and it centralizes more responsibilities

Important reduction of exchanged messages Simplified hierarchy Keeps separation between model and actual

simulator.

Finish the Flattened simulator’s design and development

Execute overhead and performance analysis using the new flattened simulator

More information:

http://www.sce.carleton.ca/faculty/wainer/wbgraf/index.html

Further workFurther work

by Ezequiel GlinskyResearch Assistant, University of Buenos Aires, Argentina

Supervisor: Prof. Gabriel A. WainerSCE, Carleton University

Overhead analysis of Overhead analysis of Discrete Event models executionDiscrete Event models execution

Thursday, November 15th, 2001

Questions?

by ezequiel glinsky research assistant, university of buenos aires, argentina

Documents