Maraninchi (Verimag, Grenoble) Simulators Synchron 08 1 / 44 - - PowerPoint PPT Presentation

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 1 / 44

Writing Simulators with Synchronous Languages

Florence Maraninchi, Nicolas Berthier, Olivier Bezet, Giovanni Funchal (with the help of Louis Mandel) Verimag / University of Grenoble

15th SYNCHRON, Aussois, december 1-5, 2008

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 1 / 44

Introduction

1

Introduction (Summary of Previous Episodes)

2

This Talk: Advertising Synchronous Languages for WSN Simulation

3

Brief Overview of SystemC

4

Brief Overview of RML

5

The Generic Example and its Encoding into RML and SC

6

Experimental Results, Comments, and Discussion

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 2 / 44

Introduction

ANR ARESA : Partners and Verimag’s role

Orange Labs Meylan Algorithms and case-studies Coronis Montpellier Provider of sensor networks TIMA-CIS Grenoble Asynchronous Hardware VERIMAG Grenoble Modeling Formalisms LIG-DRAKKAR Grenoble Network Algorithms CITI Lyon Auto-* Algorithms Verimag : A global and detailed model of a sensor network, with emphasis on energy consumption, and integrating the information provided by the other partners. First question: what needs to be in the models, what can be forgotten?... in order to predict the lifetime of the network.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 3 / 44

Introduction

Sensor Networks

Several thousands of sensors communcating by radio + a special node connected to the network (the sink). Examples: detection of a radioactive cloud, ...

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 4 / 44

Introduction

The node itself

a radio a sensor a CPU a memory a battery

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 5 / 44

Introduction

Existing Work

Network (discrete-event) simulators like NS or Opnet, no way to model energy consumption (except with very rough abstractions: “sending a message costs N units of energy”). Simulators for energy and temperature in HW (very detailed, very slow, but it is enough to observe 1mn)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 6 / 44

Introduction

Our Global Models

Simulation Models: Glonemo (in RML, with L. Samper and L. Mandel, InterSense’06) The ARESA simulator (in RML, O. Bezet) Experiments in SystemC Verification Models (more abstract): Lussensor (in Lustre, K. Baradon and A. Vasseur SLAP’07) Ifsensor (in IF, L. Mounier) Need for a semantically well-defined modeling principle for energy consumption

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 7 / 44

Introduction

Power-State Modeling of HW Elements

else a b b −a else 3t.−b 2t.−b

time

• ext. input

A B C

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 8 / 44

Introduction

Power-State Modeling of HW Elements

5 2 20

de/dt

else a b b −a else 3t.−b 2t.−b

time

• ext. input

A B C

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 8 / 44

Introduction

Power-State Modeling of HW Elements

time t 5 2 20

de/dt

else a b b −a else 3t.−b 2t.−b

time

• ext. input

A B C

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 8 / 44

Introduction

Power-State Modeling of HW Elements

−a a − − − −a − − − b time t 5 2 20

de/dt

else a b b −a else 3t.−b 2t.−b

time

• ext. input

A B C

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 8 / 44

Introduction

Power-State Modeling of HW Elements

A A A B B B C C B B A −a a − − − −a − − − b time t 5 2 20

de/dt

else a b b −a else 3t.−b 2t.−b

time

• ext. input

A B C

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 8 / 44

Introduction

Power-State Modeling of HW Elements

5 5 5 5 2 2 2 2 2 20 20 5 10 15 17 19 21 41 61 63 65 70 Cumulated energy A A A B B B C C B B A −a a − − − −a − − − b time t 5 2 20

de/dt

else a b b −a else 3t.−b 2t.−b

time

• ext. input

A B C

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 8 / 44

Introduction

Power-State Model of the Radio Component

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 9 / 44

Introduction

Building the Detailed Computational Model (1)

Radio consumption

e=... e=... e=...

x Radio Behavior (HW)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 10 / 44

Introduction

Building the Detailed Computational Model (1)

MAC protocol (SW) Radio consumption

e=... e=... e=...

x Radio Behavior (HW)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 10 / 44

Introduction

Building the Detailed Computational Model (1)

Routing protocol (SW) MAC protocol (SW) Radio consumption

e=... e=... e=...

x Radio Behavior (HW)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 10 / 44

Introduction

Building the Detailed Computational Model (1)

Application(+OS) SW Routing protocol (SW) MAC protocol (SW) Radio consumption

e=... e=... e=...

x Radio Behavior (HW)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 10 / 44

Introduction

Building the Detailed Computational Model (1)

Physical Environment Application(+OS) SW Routing protocol (SW) MAC protocol (SW) Radio consumption

e=... e=... e=...

x Radio Behavior (HW)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 10 / 44

Introduction

Building the Detailed Computational Model (1)

Channel Physical Environment Application(+OS) SW Routing protocol (SW) MAC protocol (SW) Radio consumption

e=... e=... e=...

x Radio Behavior (HW)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 10 / 44

Introduction

Building the Detailed Computational Model (2)

e=... e=... e=...

x Application(+OS) SW Routing protocol (SW) Behavior Radio (HW) Radio consumption MAC protocol (SW)

e=... e=... e=...

x Application(+OS) SW Routing protocol (SW) Behavior Radio (HW) Radio consumption MAC protocol (SW)

e=... e=... e=...

x Application(+OS) SW Routing protocol (SW) Behavior Radio (HW) Radio consumption MAC protocol (SW)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 11 / 44

Introduction

Building the Detailed Computational Model (2)

Physical Environment Channel model (perturbations, topology)

e=... e=... e=...

x Application(+OS) SW Routing protocol (SW) Behavior Radio (HW) Radio consumption MAC protocol (SW)

e=... e=... e=...

x Application(+OS) SW Routing protocol (SW) Behavior Radio (HW) Radio consumption MAC protocol (SW)

e=... e=... e=...

x Application(+OS) SW Routing protocol (SW) Behavior Radio (HW) Radio consumption MAC protocol (SW)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 11 / 44

Introduction

Building the Detailed Computational Model (2)

(Sum or tuple) & Integration

Physical Environment Channel model (perturbations, topology)

e=... e=... e=...

x Application(+OS) SW Routing protocol (SW) Behavior Radio (HW) Radio consumption MAC protocol (SW)

e=... e=... e=...

x Application(+OS) SW Routing protocol (SW) Behavior Radio (HW) Radio consumption MAC protocol (SW)

e=... e=... e=...

x Application(+OS) SW Routing protocol (SW) Behavior Radio (HW) Radio consumption MAC protocol (SW)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 11 / 44

This Talk...

1

Introduction (Summary of Previous Episodes)

2

This Talk: Advertising Synchronous Languages for WSN Simulation

3

Brief Overview of SystemC

4

Brief Overview of RML

5

The Generic Example and its Encoding into RML and SC

6

Experimental Results, Comments, and Discussion

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 12 / 44

This Talk...

Well-Defined Semantics for Multiform Time + Full-Purpose Programming Language

NS, opnet, etc.: no notion of time, very difficult to model energy consumption using power-state models. Formal asynchronous models with time: no multiform time, no programming language Synchronous Languages (especially RML) win...

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 13 / 44

This Talk...

Discrete-Events vs Fixed-Step Simulators?

From the community working on networks (and networks simulators): “Ah Ah! Forget it! You’ll never manage to do something efficient with a fixed-step simulator”. There is a reason why all simulators are based on a discrete-event engine.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 14 / 44

This Talk...

Discrete-Events vs Fixed-Step Simulators?

From the community working on networks (and networks simulators): “Ah Ah! Forget it! You’ll never manage to do something efficient with a fixed-step simulator”. There is a reason why all simulators are based on a discrete-event engine. Our (successive) answers: ...

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 14 / 44

This Talk...

Discrete-Events vs Fixed-Step Simulators? Answer 1

We don’t care, we don’t aim at building efficient simulators, we do that only in order to understand what happens in these systems. We mainly need a semantically well defined language, and there’s nothing convenient in the simulators of the domain. but... with the implicit idea that these people might be right, and that synchronous programming more or less implies fixed-step execution.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 15 / 44

This Talk...

Discrete-Events vs Fixed-Step Simulators? Answer 2, some time later...

Well, in fact, our simulator written in ReactiveML is not so bad! A model implies a lot of processes, and some simulators are not able to deal with a lot of processes (e.g., simulators in Java!).

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 16 / 44

This Talk...

Discrete-Events vs Fixed-Step Simulators? Answer 3

In a global model based on power-state modeling of energy consumption, even a discrete-event simulator will have to deal with some intrinsic events: the moments when one energy model changes consumptions.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 17 / 44

This Talk...

The Intrinsic “Something-to-do” Clock

time Work

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 18 / 44

This Talk...

Discrete-Events vs Fixed-Step Simulators? Answer 4

We will show how to exploit ReactiveML and its execution engine to

• btain an efficient simulator (not worst than what you can write with

a discrete-event simulator) because: synchronous does not necessarily imply fixed-step simulations. Modeling energy consumption means that any simulator will have something to do on the “something-to-do” clock.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 19 / 44

This Talk...

Experimental Setting for this Proof

The synchronous candidate: RML (use of ML code for the protocols) The discrete-event candidate: SystemC (good support for lots of processes, clear notion of time) No cheating: we’ll do our best in each of these languages Same system to be modeled: we stick to things that can be written in both languages (without additional costs due to heavy — and hazardous — encodings) We compare execution times (the values computed match!)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 20 / 44

Brief Overview of SystemC

1

Introduction (Summary of Previous Episodes)

2

This Talk: Advertising Synchronous Languages for WSN Simulation

3

Brief Overview of SystemC

4

Brief Overview of RML

5

The Generic Example and its Encoding into RML and SC

6

Experimental Results, Comments, and Discussion

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 21 / 44

Brief Overview of SystemC

Parallel Programming in SystemC

• 1. Threads in C++

// general C++ code // ... wait (event) ; // ... wait (N time units) ; // ... notify (event) ; //...

The set of all threads is managed by the non-preemtive scheduler. The threads run “atomically” until they explicitly yield with wait instructions.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 22 / 44

Brief Overview of SystemC

Parallel Programming in SystemC

• 2. The Non-Preemptive Scheduler

(a) END no eligible process no eligible process no eligible process ELAB EV UP TE

elect a process and run it advance simulation time signal values update platform build the

(b) EV UP EV UP TE EV ELAB δ time ∃ eligible process ∃ eligible process ∃ eligible process

t=0 t=t+d

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 23 / 44

Brief Overview of SystemC

Parallel Programming in SystemC

• 3. A Note on Time, and Time Granularity

When all processes are waiting for events to occur, of for time to pass, the scheduler advances time until the smallest value that will wake up some processes. Having components that run at various time granularities is not a

• problem. Multiplying all time constants by some constant K has no

influence on the execution time. while (1) { wait(100000) ; do something ; } in parallel with while (1) { wait (1) ; do something else ; }

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 24 / 44

Brief Overview of RML

1

Introduction (Summary of Previous Episodes)

2

This Talk: Advertising Synchronous Languages for WSN Simulation

3

Brief Overview of SystemC

4

Brief Overview of RML

5

The Generic Example and its Encoding into RML and SC

6

Experimental Results, Comments, and Discussion

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 25 / 44

Brief Overview of RML

Parallel Programming in ReactiveML

• 1. ML + reactive constructs

loop await immediate one input_signal (value) in await immediate s_time_increased; emit !restart false; let timeout = transition in if timeout > 0 then emit launch_timeout timeout; pause end ||loop await launch_timeout (value) in let timeout = List.hd value in let handler sign () = emit sign true in emit subscribe_timeout (timeout, handler !restart); await immediate one !restart (value) in if value then begin let timeout = on_timeout () in if timeout > 0 then emit launch_timeout timeout; end; restart := new_signal ();

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 26 / 44

Brief Overview of RML

Parallel Programming in ReactiveML

• 2. Semantics of the reactive constructs

Based on the reactive programming principle (F. Boussinot), avoiding the need for a global static causality analysis. Implementation: partly event-driven (the processes that wait for an event are stored in a queue associated with this event, all these queues are associated with some nodes of the syntactic tree).

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 27 / 44

Brief Overview of RML

Parallel Programming in ReactiveML

• 3. A Note on Time and Time Granularity

Time is defined by the base clock, as in all synchronous languages. wait(100000); means that, something, somewhere, has to count from 1 to 100000. – Multiplying the delays by some constant K has an influence – Parallel Processes at various granularities might be a problem...

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 28 / 44

The Generic Example and its Encoding into RML and SC

1

Introduction (Summary of Previous Episodes)

2

This Talk: Advertising Synchronous Languages for WSN Simulation

3

Brief Overview of SystemC

4

Brief Overview of RML

5

The Generic Example and its Encoding into RML and SC

6

Experimental Results, Comments, and Discussion

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 29 / 44

The Generic Example and its Encoding into RML and SC

Common Structure (1)

(stub) Gen. Event Functional part of the model

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 30 / 44

The Generic Example and its Encoding into RML and SC

Common Structure (1)

d2 d3 d1 d2 d3 d1 a b c d b a c d Non−Functional Parts id=2 id=1 (stub) Gen. Event Functional part of the model

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 30 / 44

The Generic Example and its Encoding into RML and SC

Common Structure (1)

d2 d3 d1 d2 d3 d1 a b c d b a c d Non−Functional Parts id=2 id=1 (stub) Gen. Event Functional part of the model

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 30 / 44

The Generic Example and its Encoding into RML and SC

Common Structure (1)

Integrator d2 d3 d1 d2 d3 d1 a b c d b a c d Non−Functional Parts id=2 id=1 (stub) Gen. Event Functional part of the model

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 30 / 44

The Generic Example and its Encoding into RML and SC

Common Structure (1)

id + energy of the new state

Integrator d2 d3 d1 d2 d3 d1 a b c d b a c d Non−Functional Parts id=2 id=1 (stub) Gen. Event Functional part of the model

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 30 / 44

The Generic Example and its Encoding into RML and SC

Common Structure (2)

The functional part of the model does not make use of time The event generator mimicks the environment: it waits for some time and emits events for the functional part The non-functional parts are energy automata; transitions are triggered by events from the funvcional part, or because a state time-out has been reached. We run 10000 units of time of a model made of 10000 such objects (slightly desynchronized for their starting point).

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 31 / 44

The Generic Example and its Encoding into RML and SC

Common Structure (3)

The experiment: one of the automata is driven in such a way that it changes states quite often, and the other one changes states quite rarely. We’d like to observe that the encoding of an automaton “works” only when needed.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 32 / 44

The Generic Example and its Encoding into RML and SC

Principles of the Encoding into RML

• 1. A Global Manager for Timers

Idea: mimick the SC scheduler advancing time by chunks... for everybody except the time manager. In RML, there’s a unique process that follows the basic clock. All the

• ther ones are event-driven.

Timers are never cancelled.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 33 / 44

The Generic Example and its Encoding into RML and SC

Principles of the Encoding into RML 1’. A Global Manager for Timers

5 10 4 emit newe(self, 10) emit newe(self, 5) ... newe (id, val) id=1: current=x1 id=2: current=x2 .... Sum = X expire(id) A emit timer(self,10) await expire(self) timer(id,val) Timekeeper (a priority queue encoded as a heap) x

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 34 / 44

The Generic Example and its Encoding into RML and SC

Principles of the Encoding into RML

• 2. Avoid Combined Conditions

Each process listens for its inputs on a single channel, and tests the value afterwards: await input (value) in if value = ... then ... The encoding of a transition label of the form a ∧b ∨c with nested await statements is quite inefficient (at least the form we tried).

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 35 / 44

The Generic Example and its Encoding into RML and SC

Principles of the Encoding into SystemC

Each automaton is a process. Processes can call functions to compute the energy consumed. They can call a special function of the scheduler called What time is it? Timers are managed by the scheduler in a standard way

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 36 / 44

The Generic Example and its Encoding into RML and SC

Wrap-up

The language RML ∩ SC: Imperative code and parallelism at the main level, and for waiting for several events Wait for time Wait for simple positive events (nothing like wait(a ∧¬b) or wait(¬b)) Emit (or notify) events It can be implemented in an “event-driven” way (with queues of processes waiting for events).

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 37 / 44

Experimental Results, Comments, and Discussion

1

Introduction (Summary of Previous Episodes)

2

This Talk: Advertising Synchronous Languages for WSN Simulation

3

Brief Overview of SystemC

4

Brief Overview of RML

5

The Generic Example and its Encoding into RML and SC

6

Experimental Results, Comments, and Discussion

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 38 / 44

Experimental Results, Comments, and Discussion Maraninchi (Verimag, Grenoble) Simulators Synchron 08 39 / 44

Experimental Results, Comments, and Discussion Maraninchi (Verimag, Grenoble) Simulators Synchron 08 40 / 44

Experimental Results, Comments, and Discussion Maraninchi (Verimag, Grenoble) Simulators Synchron 08 41 / 44

Experimental Results, Comments, and Discussion

Conclusion (not really a scoop)

The efficiency of an event-driven simulator is not due to the execution mechanics (although it should not be programmed with a ladle).

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 42 / 44

Experimental Results, Comments, and Discussion

Conclusion (not really a scoop)

The efficiency of an event-driven simulator is not due to the execution mechanics (although it should not be programmed with a ladle).

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 42 / 44

Experimental Results, Comments, and Discussion

Conclusion (not really a scoop)

The efficiency of an event-driven simulator is not due to the execution mechanics (although it should not be programmed with a ladle). It is mainly due to the intrinsic lack of expressivity of the associated programming or modeling languages, that make it possible to have costless waiting processes, and to ignore long periods of time.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 42 / 44

Experimental Results, Comments, and Discussion

Conclusion (not really a scoop)

We get a comparable efficiency in ReactiveML because: Louis Mandel does not program with a ladle! We avoid the programs in which all th parts have to do something to do at each tick. We don’t ignore completely some periods of time, but the only thing that has to be done each tick is counting.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 43 / 44

Experimental Results, Comments, and Discussion

Conclusion (not really a scoop)

We get a comparable efficiency in ReactiveML because: Louis Mandel does not program with a ladle! We avoid the programs in which all th parts have to do something to do at each tick. We don’t ignore completely some periods of time, but the only thing that has to be done each tick is counting. This would be the case with any imperative reactive (a la Boussinot) language, because of the notion of an event (as opposed to a flow), and because reactive is a bit less expressive then pure synchrony.

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 43 / 44

Experimental Results, Comments, and Discussion

Further Work

Towards faster than real-time simulators for sensor networks... (keeping the computational model of energy consumption, i.e., energy automata for all the HW parts)

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 44 / 44

Experimental Results, Comments, and Discussion

Further Work

Towards faster than real-time simulators for sensor networks... (keeping the computational model of energy consumption, i.e., energy automata for all the HW parts)

1

First step: use a fully event-driven subset of ReactiveML

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 44 / 44

Experimental Results, Comments, and Discussion

Further Work

Towards faster than real-time simulators for sensor networks... (keeping the computational model of energy consumption, i.e., energy automata for all the HW parts)

1

First step: use a fully event-driven subset of ReactiveML

2

Second step: forget more details, abstract the energy modes of a sensor = ⇒ a lot of program transformations, definitely easier to perform in a language with a clean semantics

Maraninchi (Verimag, Grenoble) Simulators Synchron 08 44 / 44