Modular Performance Analysis with Real-Time Calculus · Computer Engineering and Networks Laboratory (TIK) 2 Presentation overview Introduction to System Level Performance Analysis

Modular Performance Analysis withReal-Time Calculus

Wolfgang Haid, Simon Perathoner, Nikolay Stoimenov, Lothar Thiele

ARTIST2 PhD Course on Automated Formal Methods for Embedded SystemsDTU - Lyngby, Denmark - June 11, 2007

Computer Engineering and Networks Laboratory (TIK) 2

Presentation overviewIntroduction toSystem Level

Performance Analysis(Simon Perathoner)

ModularPerformance Analysis

(MPA)(Nikolay Stoimenov)

Real-Time Calculus(RTC)

(Wolfgang Haid)

Extensions to basic model(Wolfgang Haid)

Real-Time Interfaces(RTI)

(Nikolay Stoimenov)

Comparison withother approaches

(Simon Perathoner)


Simon Perathoner

1. Introduction to System Level Performance Analysis



Embedded Real-Time Systems

Design & Analysis

Special-purpose information processing systems Embedded into larger productsMust meet real-time constraints


Trends in Embedded System Design

parallel

distributed

heterogeneous

Architectures are increasingly:

Analysis and prediction ofsystem behavior is complex!


System Level Performance Analysis

EmbeddedReal-Time System

InputStream

InputStream


System level performance Analysis

Computational Resources ...

InputStream

InputStream

DSP I/O

μPCPU



... Communication Resources ...


InputStream

InputStream

DSP I/O

μPCPU




... Communication Resources ...

... Tasks (HW/SW Components)

InputStream

InputStream

I/O

μP

T4 T6

T3

T5

T2T1



InputStream

InputStream

I/O

μP

T4 T6

T3

T5

T2T1

Memory Requirements?

Processor Speeds?

Timing Properties?

Bus Utilization?

Bottleneck?


Role in the design process

Application Architecture

AllocationMapping

Scheduling

Performance Analysis

Design SpaceExploration


Challenges of Performance Analysis

InputStream

Complex Input:- Timing (jitter, bursts, ...)- Different Event Types

Task CommunicationResource sharing (Scheduling)

ab acc b


Processor

Task

BufferInputStream

Task CommunicationResource sharing (Scheduling)

ab acc b

Complex Input:- Timing (jitter, bursts, ...)- Different Event Types

Variable Resource AvailabilityVariable Execution Demand- Input (different event types)- Internal State (Program, Cache, ...)

Challenges of Performance Analysis


Formal Analysis vs. Simulation e.g. delay

Real System Simulation Formal analysis

Best-Case

Worst-Case

upper bound

lower bound


Requirements for a formal PA method

Correctness

Accuracy

Embedding into the design process

Modularity

Short analysis time

5-1Swiss FederalInstitute of Technology

Computer Engineeringand Networks Laboratory

Modular Performance Analysis- Models, Methods and Scenarios -

© Nikolay Stoimenov

ETH Zurich, Switzerland



Outline

• Modular Performance Analysis

• MPA Case Study



Analysis and Design

Embedded System =

Computation + Resource Interaction

Analysis: Infer system properties from subsystem properties.

Design: Build a system from subsystems while meeting requirements.



Challenges

Make Analysis and Synthesis Compositional

Stepwise Refinement: a. compose subsystemsb. refine subsystems

Adaptivity: a. changes in environmentb. changes of requirements



Modular Performance Analysis

Service Model(Resources)

Load Model(Environment)

PerformanceModel

Processing Model(HW/SW)

Analysis

Analysis Results

Input traces

Formalspecification

System Model

Application Architecture

MappingScheduling

UML sequencediagrams Task graphs UML/SysML

diagrams

Formalspecification

Componentsimulation

Measure-ments

Data sheets



Abstract Models for Performance Analysis

ProcessorTask

InputStream

ServiceModel

LoadModel

Concrete InstanceAbstract Representation

ProcessingModel



Load Model (Environment)

t [ms]

eventsEvent Stream

maximum / minimumarriving demand in anyinterval of length 2.5 ms

2.5

Arrival Curve α & Delay ddemand

Δ [ms] 2.5

number of events in in t=[0 .. 2.5] ms

deadline = d

ServiceModel

LoadModel

ProcessingModel

αlαu



Load Model - Examplesperiodic periodic w/ jitter

periodic w/ burst complex

ServiceModel

LoadModel

ProcessingModel



Service Model (Resources)

t [ms]

availabilityResource Availability

maximum/minimumavailable service in anyinterval of length 2.5 ms

available service in t=[0 .. 2.5] ms

2.5

βu

βl

Service Curves [βl, βu]service

Δ [ms] 2.5

ServiceModel

LoadModel

ProcessingModel



Service Model - Examplesfull resource bounded delay

TDMA resource periodic resource

ServiceModel

LoadModel

ProcessingModel



Processing Model (HW/SW)

HW/SW Components

Abstract Components

ServiceModel

LoadModel

ProcessingModel

αβ

β’

α’

Processing semantics and functionality of hardware

or software tasks

RTC



Processing Model – ExamplesServiceModel

LoadModel

ProcessingModel

• Component is triggered by incoming events.

• A fully preemptable task is instantiated at every event arrival to process the incoming event.

• Active tasks are processed in a greedy fashion in FIFO order.

• Processing is restricted by the availability of resources.

Behavioral DescriptionGreedy Processing Component




LoadModel

ProcessingModel

[αl, αu]

[βl, βu]

[βl’, βu’]

[αl’, αu’]

GPC

Greedy Processing Component

Real-Time Calculus




LoadModel

ProcessingModel

• Delays incoming events such that the output conforms to a given traffic specification.

• Guarantees that no events get delayed any longer than necessary.

• Works also with bursty traffic specifications.

Greedy Shaper Component

Behavioral Description




LoadModel

ProcessingModel

[αl, αu]

[σ]

[αl’, αu’]

GSC

Greedy Shaper ComponentReal-Time Calculus



System CompositionCPU BUS DSP

GPC GPC

GPC GPC

GPC GSC

How to inter-connect service?

RM TDMA

Scheduling!



FP/RM EDF RR

TDMAGPS

Scheduling and Arbitration

GPC

GPC

GPC

GPC

EDF RR

sum

share

GPC

GPC

TDMA



RR

Mixed Hierarchical Scheduling

FP

TDMA

EDF

RR

EDFTDMA FP/RM+

FP

FP/RM EDF+

EDF

FP

RR EDF+

FP/RM RR+

FP/RM GPS+

GPS EDF+

. . .

…and many othercombinations:



Hierarchical Scheduling with ServersStatic Polling Server

SPS

FP

FP

any

Dynamic Polling Server

DPS

any

EDF



Complete System CompositionCPU BUS DSP

RM TDMA

GPC GPC

GPC GPC

GPC GSC

TDMA



Analysis: Delay and Backlog

delay dmax

backlog bmax

βl

αu[αl, αu]

[βl, βu]

[βl’, βu’]

[αl’, αu’]

GPC



Extending the Framework

• New HW behavior• New SW behavior• New scheduling scheme• ...

αβ

β’

α’RTC

• Find new relations:

This is the hard part…!



MPA-RTC

Embedding with other Frameworks

{P, J, D}

{P, J, D}

Lossy Converter

Lossless Converter

MPA-RTC SystemCSimulation

Trace Generator

Trace Analyzer



Outline

• Modular Performance Analysis

• MPA Case Study



Case Study

ECU1

BUS

CC1

ECU2 CC2

ECU3CC3

S1

S2

S3

S4

S5

6 Real-Time Input Streams- with jitter- with bursts- deadline > period

3 ECU’s with own CC’s

13 Tasks & 7 Messages- with different WCED

2 Scheduling Policies- Earliest Deadline First (ECU’s)- Fixed Priority (ECU’s & CC’s)

Hierarchical Scheduling- Static & Dynamic Polling Servers

Bus with TDMA- 4 time slots with different lengths(#1,#3 for CC1, #2 for CC3, #4 for CC3)

Total Utilization:- ECU1 59 %- ECU2 87 %- ECU3 67 %- BUS 56 %

S6



Specification Data



The Distributed Embedded System...ECU1 BUS

(TDMA)

C1.1

C1.2

C2.1

C3.1

C4.1

C5.1

C3.2

T1.1

T1.3T2.1

T3.1

T3.3

PS

FPFP

CC1

ECU2

T4.1

T5.1

FPCC2

ECU3

T1.2

FP FP

CC3

T3.2

FP

EDF

T2.2

PS

T4.2

PS

T5.2

S1

S2

S3

S4

S5

S1

S3

T6.1S6

S6



... and its MPA Model

S5

S4

S1

S2

S3

T1.1

T1.3

C4.1

C5.1

CPU

T2.1

T3.1

CPU

T4.1

T5.1

CPU

PS

T1.2

EDF

PS

T3.2

C1.2

C3.2

C2.1

C3.1

C1.1

T5.2

T4.2

T2.2

PS

ECU1

ECU2

ECU3BUS

CC1

CC2

CC3

T6.1S6

T3.3

TDMA



Buffer & Delay Guarantees

S5

S4

S1

S2

S3

T1.1

T1.3

C4.1

C5.1

CPU

T2.1

T3.1

CPU

T4.1

T5.1

CPU

PS

T1.2

EDF

PS

T3.2

C1.2

C3.2

C2.1

C3.1

C1.1

T5.2

T4.2

T2.2

PS

ECU1

ECU2

ECU3BUS

CC1

CC2

CC3

T6.1S6

T3.3

2

62

2

57 1

313

5

5

1

4

5

6

5

5.30

7.12

3.69

d

b

1.80

0.50

0.70

TDMA



Adding Greedy Shapers

S5

S4

S1

S2

S3

T1.1

T1.3

C4.1

C5.1

CPU

T2.1

T3.1

CPU

T4.1

T5.1

CPU

PS

T1.2

EDF

PS

T3.2

C1.2

C3.2

C2.1

C3.1

C1.1

T5.2

T4.2

T2.2

PS

ECU1

ECU2

ECU3BUS

CC1

CC2

CC3

T6.1S6

T3.3

2

62

2

57 1

313

5

5

1

4

5

6

5

5.30

7.12

3.69

1.80

0.50

0.70

2.704

: - 27%: - 20%

DelayBuffer

TDMA



Input of Stream 3

S5

S4

S1

S2

S3

T1.1

T1.3

C4.1

C5.1

CPU

T2.1

T3.1

CPU

T4.1

T5.1

CPU

PS

T1.2

EDF

PS

T3.2

C1.2

C3.2

C2.1

C3.1

C1.1

T5.2

T4.2

T2.2

PS

ECU1

ECU2

ECU3BUS

CC1

CC2

CC3

T6.1S6

T3.3

TDMA



Output of Stream 3

S5

S4

S1

S2

S3

T1.1

T1.3

C4.1

C5.1

CPU

T2.1

T3.1

CPU

T4.1

T5.1

CPU

PS

T1.2

EDF

PS

T3.2

C1.2

C3.2

C2.1

C3.1

C1.1

T5.2

T4.2

T2.2

PS

ECU1

ECU2

ECU3BUS

CC1

CC2

CC3

T6.1S6

T3.3

TDMA



Output of Stream 3 with Greedy Shapers

S5

S4

S1

S2

S3

T1.1

T1.3

C4.1

C5.1

CPU

T2.1

T3.1

CPU

T4.1

T5.1

CPU

PS

T1.2

EDF

PS

T3.2

C1.2

C3.2

C2.1

C3.1

C1.1

T5.2

T4.2

T2.2

PS

ECU1

ECU2

ECU3BUS

CC1

CC2

CC3

T6.1S6

T3.3

TDMA



System Analysis Time

• 10 seconds – Pentium Mobile 1.6 GHz– Matlab 7 SP2– RTC Toolbox



RTC Toolbox: Version 1.0 Released

www.mpa.ethz.ch/rtctoolbox



RTC Toolbox: Simulink Frontend

Currently under Development



Acknowledgement

• Collaborators:– Ernesto Wandeler– Samarjit Chakraborty– Simon Künzli– Alexander Maxiaguine– Kai Huang

• Funding:– SNF, KTI, MEDEA+/SPEAC, ARTIST2 NoE

Swiss FederalInstitute of Technology


Thank you!


Nikolay [email protected]

IntroductionMin-Plus Calculus

Real-Time Calculus

Real-Time Calculus———————————–

A Formal Method for the Analysis ofReal-Time Systems

Wolfgang Haid

DTU, June 11, 2007

Wolfgang Haid Real-Time Calculus


Real-Time Calculus

OverviewOutlineApplication and Foundation

Overview

Real-Time Calculus (RTC)

Modular Performance Analysis (MPA)

Min-Plus Calculus, Max-Plus Calculus

system view

mathematical view


1/20


Real-Time Calculus


Outline

Min-Plus Calculus

Basic Abstractions

System Modeling

System Analysis


2/20


Real-Time Calculus


Application and Foundation

Application of Real-Time Calculus

Real-Time Calculus can be regarded as a worst-case/best-casevariant of classical queuing theory. It is a formal method for theanalysis of real-time embedded systems.

Foundation of Real-Time Calculus

Min-Plus Algebra: F. Baccelli, G. Cohen, G. J. Olster, and J.P. Quadrat, Synchronization and Linearity — An Algebra forDiscrete Event Systems, Wiley, New York, 1992.

Network Calculus: J.-Y. Le Boudec and P. Thiran, NetworkCalculus — A Theory of Deterministic Queuing Systems forthe Internet, Lecture Notes in Computer Science, vol. 2050,Springer Verlag, 2001.

Formal methods for system level performance analysis


3/20


Real-Time Calculus

Min-Plus vs. Plus-Times CalculusMin-Plus/Max-Plus Operators

Comparison of Algebraic Structures (I)

Algebraic Structure

set of elements Sone or more operators defined on elements of this set

Algebraic Structures With Two Operators �, �

plus-times: {R, +, ×}min-plus: {R ∪+∞, inf, +}

inf - Reminder

inf(S) is the greatest lower bound of the elements in a set S.

inf{[3, 4]} = 3, inf{(3, 4]} = 3

min{[3, 4]} = 3, min{(3, 4]} not defined


4/20


Real-Time Calculus


Comparison of Algebraic Structures (II)

Common Properties: �

Closure of �: a � b ∈ SAssociativity of �: a � (b � c) = (a � b) � c

Commutativity of �: a � b = b � a

Existence of identity element for �: ∃ν : a � ν = a

Existence of negative element for �: ∃a−1 : a � a−1 = ν

Zero element for � absorbing for �: a � ε = ε

Distributivity of � w.r.t. �: a � (b � c) = a� b � b × c

Example: Distributive Law

plus-times: a× (b + c) = a× b + b × c

min-plus: a + inf{b, c} = inf{a + b, a + c}


5/20


Real-Time Calculus


Comparison of Algebraic Structures (III)

Common Properties: �Closure of �: a� b ∈ SAssociativity of �: : a� (b � c) = (a� b)� c

Commutativity of �: a� b = b � a

Existence of identity element for �: ∃ε : a� ε = a

Different Properties: �Existence of negative element for �: ∃ − a : a� (−a) = ε

Idempotency of �: a� a = a


6/20


Real-Time Calculus


Comparison of System Theories

Plus-Times System Theory h(t) = (f � g)(t) = Z t0 f(t� s) � g(s) dsg(t)f(t)signals

impulse response

convolution

time domain

Min-Plus System TheoryR(�) g(�) R0(�) � (R g)(�) = inf0��ff(�� ) + g(�)gstreams

service/shaping curve

min-plus convolution

time-interval domain


7/20


Real-Time Calculus


Min-Plus/Max-Plus Convolution and Deconvolution

Definitions

min-plus convolution:(f ⊗ g)(∆) = inf0≤λ≤∆

{f (∆− λ) + g(λ)}

min-plus deconvolution:(f � g)(∆) = supλ≥0

{f (∆ + λ)− g(λ)}

max-plus convolution:(f⊗g)(∆) = sup0≤λ≤∆

{f (∆− λ) + g(λ)}

max-plus deconvolution:(f�g)(∆) = infλ≥0

{f (∆ + λ)− g(λ)}

Duality between ⊗ and �f ≤ g ⊗ h ⇔ f � h ≤ g


8/20


Real-Time Calculus

System ModelSystem AnalysisSummary

From Streams to Cumulative Functions

Cumulative Functions

1 2 3 4 5 6 7 80

5

10

15

20

C(t)R(t)

1 2 3 4 5 6 7 80

1

1 2 3 4 5 6 7 80

1

time t

data streams: R(t) := number of events in [0, t)

resource streams: C (t) := available resources in [0, t)


9/20


Real-Time Calculus


Greedy Processing (I)

R(t) R0(t)C(t)C 0(t)

0 1 2 3 4 5 6 7 80

5

10

15

20

25

30

t

pro

cess

ing

time

dem

and

avai

labl

e pr

oces

sing

tim

e

C(t)C’(t)R(t)R’(t)B(t)C(t) − R(t)

Elementary Relations

C (t) = C ′(t) + R ′(t)

B(t) = R(t)− R ′(t)


10/20


Real-Time Calculus


Greedy Processing (II)

Input/Output Relation

0 1 2 3 4 5 6 7 80

5

10

15

20

25

30

t

pro

cess

ing

time

dem

and

avai

labl

e pr

oces

sing

tim

e

C(t)C’(t)R(t)R’(t)B(t)C(t) − R(t)

R ′(t) = C(t)− C ′(t) = C(t)− sup0≤ s ≤ t

{C(s)− R(s)} |inf{S} = sup−S

= C(t) + inf0≤ s ≤ t

{R(s)− C(s)}

= inf0≤ s ≤ t

{R(s) + C(t)− C(s)} |periodic resource

= inf0≤ s ≤ t

{R(s) + C(t − s)} != (R ⊗ C)(t)


11/20


Real-Time Calculus


From Cumulative Functions To Bounding Curves

R(t) R0(t)C(t)C 0(t) �(�) �0(�)�(�)

� 0(�)Wolfgang Haid Real-Time Calculus

12/20


Real-Time Calculus


Arrival and Service Curves

Definition

0 1 2 3 4 5 6 7 80

5

10

15

20

25

time interval ∆

βu

βl

αu

αl

CR

αl(t − s) ≤ R[s, t) ≤ αu(t − s), ∀s < t,

βl(t − s) ≤ C [s, t) ≤ βu(t − s), ∀s < t,

αu(0) = αl(0) = βu(0) = βl(0) = 0.


13/20


Real-Time Calculus


Upper Arrival Curve (I)

Stream Constraint

R(t) ≤ (R ⊗ αu)(t)

= inf0≤s≤t

{R(s) + αu(t − s)}

≤ R(s) + αu(t − s), ∀ 0 ≤ s ≤ t

⇔R(t)− R(s) ≤ αu(t − s), ∀s ≤ t


14/20


Real-Time Calculus


Upper Arrival Curve (II)

Upper Arrival Curve

αu(∆) = (R � R)(∆)

= sups≥0

{R(∆ + s)− R(s)} |∆ = t − s

= sups≥0

{R(t − s + s)− R(s)}

≥ R(t)− R(s), ∀t ≥ s

(R � R): Minimum Upper Arrival Curve

Assume αu is an upper arrival curve for R.

from previous slide: R ≤ R ⊗ αu

from duality property: R � R ≤ αu


15/20


Real-Time Calculus



Input/Output Relations

h�l; �ui h�l; �ui h�0l; �0uih� 0l; � 0ui0 1 2 3 4 5 6 7 8

0

5

10

15

20

25

time interval ∆

β’u

β’l

α’u

α’l

C’R’

α′u = min{(αu ⊗ βu)� βl , βu}, α′l = min{(αl � βu)⊗ βl , βl}β′u = (βu − αl) � 0, β′l = (βl − αu) ⊗ 0


16/20


Real-Time Calculus


Backlog and Delay (I)

Definition

maximum backlog B

maximum delay D

�l �u�

B = sup0≤λ

{αu(λ)− βl(λ)

}D = sup

∆≤0

{inf

{τ ≤ 0 : αu(∆) ≤ βl(∆ + τ)

}}Wolfgang Haid Real-Time Calculus

17/20


Real-Time Calculus


Backlog and Delay (II)

Backlog Bound

B(t) = R(t)− R ′(t) = R(t)− inf0≤u≤t

{R(u) + C (t)− C (u)}

= sup0≤u≤t

{(R(t)− R(u))− (C (t)− C (u))}

≤ sup0≤u≤t

{αu(t − u)− βl(t − u)}

≤ sup0≤λ

{αu(λ)− βl(λ)}

= (αu � βl)(0)


18/20


Real-Time Calculus


Backlog and Delay (III)

D

B

B

D


19/20


Real-Time Calculus


Summary: Fixed-Priority Scheduling

Key Elements of Real-Time Calculus

min-plus calculus as well-definedmathematical basis

abstraction of streams: arrival/servicecurves

abstraction of processing: greedyprocessing

delay and backlog bounds

modularity

�1(�) �01(�)�(�)

� 0(�)�2(�) �02(�)�3(�) �03(�)


20/20

IntroductionModel and Analysis

Conclusion

Complex Task Activation Schemesin


Wolfgang Haid

DTU, June 11, 2007

Wolfgang Haid Complex Task Activation Schemes


Conclusion

ContextOutlineFormal Methods for System Level Performance Analysis

Context

Keywords

Distributed embedded real-time systems

System level performance analysis

Formal methods for system level performance analysis


1/13


Conclusion


A Glimpse on Formal Methods

Advantages

Hard bounds

Complete coverage of corner cases

Faster than simulation

Drawbacks

Limited modeling capabilities

Bounds potentially not tight

Inaccuracy of results

Thesis

To obtain improved accuracy, we can sacrifice some computationaleffort.


2/13


Conclusion


Outline

Introduction to complex task activation schemes

Task model and analysis

MPEG-2 case study

Conclusion


3/13


Conclusion


Formal Methods

Frameworks

Modular Performance Analysis / Real-Time Calculus(MPA/RTC): Samarjit Chakraborty, Simon Kunzli, and LotharThiele, A General Framework for Analyzing System Propertiesin Platform-Based Embedded System Design, Proc. 6thDesign, Automation and Test in Europe (DATE) (Munich,Germany), March 2003, pp. 190–195.

Symbolic Timing Analysis for Systems (SymTA/S): RafikHenia, Arne Hamann, Marek Jersak, Razvan Racu, KaiRichter, and Rolf Ernst, System Level PerformanceAnalysis — The SymTA/S Approach, IEE ProceedingsComputers and Digital Techniques 152 (2005), no. 2,148–166.


4/13


Conclusion


Formal Methods

Example: MPEG-2 on Multiprocessor Platform

BUS

B C

D R2R1FG

RISC DSP

A

E

H

stre

am

task function

video

A VLD, IQ, ISB data transferC IDCT, MCD data transferE assemble video-frames

audio

F DEC, IMDCT, SYNG data transferH assemble audio-frames

But . . .

Tasks have usually more than one input.

The activation of tasks can depend on complex activationschemes.


5/13


Conclusion


Formal Methods

Example: MPEG-2 on Multiprocessor Platform

BUS

B C

D R2R1FG

RISC DSP

A

E

H

stre

am

task function

video

A VLD, IQ, ISB data transferC IDCT, MCD data transferE assemble video-frames

audio

F DEC, IMDCT, SYNG data transferH assemble audio-frames

But . . .

Tasks have usually more than one input.

The activation of tasks can depend on complex activationschemes.


5/13


Conclusion

Task Model, Terms, and NotationAnalysis PrincipleNon-Preemptive Fixed Priority Scheduling

Task Model

1: if test(reconfig) then . execute subtask A2: execute code that reconfigures the task;3: else if test(dataA) or test(dataB) then . execute subtask B4: process first event arrived at dataA or dataB;5: write to outputA;6: else if test(dataC) and test(dataD) then . execute subtask C7: process first event in dataC and in dataD;8: write to outputB;9: end if

reconfig

dataA

dataB

dataC

dataD

outputA

outputB

A

B

C


6/13


Conclusion



h�l; �uih�l; �ui

GPCh�0l; �0uih� 0l; � 0ui

0 5 10 15 200

10

20

30

time interval ∆

#(ev

ents

) d

uri

ng

∆

Input Arrival Curves

0 5 10 15 200

10

20

30

40

time interval ∆

#(ev

ents

) d

uri

ng

∆

Input Service Curves

0 5 10 15 200

10

20

30

time interval ∆

#(ev

ents

) d

uri

ng

∆

Output Arrival Curves

0 5 10 15 200

5

10

15

20

25

time interval ∆

#(ev

ents

) d

uri

ng

∆

Output Service Curves

αu

αlβu

βl

α’u

α’lβ’u

β’l

arrival curve α : αl(t − s) ≤ R(t)− R(s) ≤ αu(t − s),

service curve β : βl(t − s) ≤ C (t)− C (s) ≤ βu(t − s), ∀t − s ≥ 0


7/13


Conclusion


Analysis Principle

A

B

C

A

B

C

non-preemptivefixed priority

scheduler

A

B

C

non-preemptivefixed priority

scheduler

OR

AND


8/13


Conclusion


Non-Preemptive Fixed Priority Scheduling

Related Work: Priority Queuing in Network Queueing Theory

Jean-Yves Le Boudec and Patrick Thiran, NetworkCalculus — A Theory of Deterministic Queuing Systems forthe Internet, Lecture Notes in Computer Science, vol. 2050,Springer Verlag, 2001.

Jens Schmitt, On Average and Worst Case Behavior inNon-Preemptive Priority Queueing, Proc. 2003 Intl Symp. onPerformance Evaluation of Computer and TelecommunicationSystems, 2003, pp. 197–204.


9/13


Conclusion



Relations for Preemptive Fixed Priority Scheduling

βui (∆) = inf

λ≥0

βu(∆ + λ)−N∑

j=i+1

αlj(∆ + λ)

βl

i (∆) = sup0≤λ≤∆

βl(∆− λ)−N∑

j=i+1

αuj (∆− λ)

i . . . task priority N . . . number of tasks


10/13


Conclusion



Relations for Non-Preemptive Fixed Priority Scheduling

βui (∆) = min

{βu(∆), inf

λ≥0

{βu(∆ + λ)−

N∑j=i+1

αlj(∆ + λ)

}+Cmax

i

}

β li (∆) = max

{0, sup

0≤λ≤∆

{β l(∆− λ)−

N∑j=i+1

αuj (∆− λ)

}− max

1≤j<i

{Cmax

j

}}

i . . . task priority N . . . number of tasks

Cmaxi . . .maximum number of resource units to process one event


11/13


Conclusion

MPEG-2 Case StudyContributions

MPEG-2 Case Study

BUS

B C

D R2R1

FG

RISC DSP

R3time ref

A

E

H

I


12/13


Conclusion

MPEG-2 Case StudyContributions

Contributions

Consideration of complex task activation schemes based onAND/OR semantics

Modeling of tasks with complex activation schemes in MPAusing abstract AND/OR components and non-preemptivefixed priority scheduling

Derivation and proof of input-output relations of abstractAND/OR component

Derivation and proof of relations to model non-preemptivefixed priority scheduling

Application of the results in an MPEG-2 case study


13/13



Real-Time Interfaces

© Nikolay Stoimenov

ETH Zurich, Switzerland



Outline

• Real-Time Interfaces / Interface-Based Design

• IBD Case Study



Real-Time Interfaces &Interface-Based Design



Component-Based Design

FP

FP

1. Design

2. Analysis– Given: all components, their

interconnections structure and all inputs from environment

– Question: do the components work together properly?

Schedulable?

Constraints:



Interface-Based Design

FP

FPConstraints:

1. Design and Composition– Given: some components,

their interconnection structure and some inputs from environment

– Questions: Is there the chance that the components work together properly? What are the assumptions towards the environment? How can I change the environment such that the components still work together?

?

?



Interface-Based Design

Component Description:

What Does a Component Do?

Component Interface:

How Can a Component Be Used?

vs.




Interface-Based Design(Assume/Guarantee Interfaces)

Henzinger, de Alfaro, et al.

Real-Time Calculus

Thiele, et al.




From a Simple Component ...

resource supply

remaining resources

resource demand



... to its A/G Interface

resource supply

remaining resources

resource demand




resource supply

remaining resources

resource demand

Variables & Types




Input Assumptions, Predicates & Values




Output Guarantees, Predicates & Values




Data from Other Component Interfaces




Internal Interface Relations



Compatibility & Composition



The Weakest Environment

0

0∞∞

0∞



A Simple Example

0

0∞∞

0∞

0

0∞∞

0∞



A Simple Example

0

0∞∞

∞

0

0∞

0∞5

∞



A Simple Example

0

∞∞

∞

∞

0∞5

5

507



A Simple Example

0

05

75

577

2

2



A Simple Example

0

05

75

5

4

∞

7

2

2

7



A Simple Example

0

05

75

5

1

∞

7

2

2

7



A Simple Example

05

7

5

2

1

6

1

66



Foundations of Real-Time Interfaces

Interface-Based Design(Assume/Guarantee Interfaces)

Henzinger, de Alfaro, et al.

Real-Time Calculus

Thiele, et al.




Three Steps to Real-Time Interfaces

• Step 1: Abstract Components

• Step 2: Interface Variables and Predicates

• Step 3: Internal Interface Relations



Step 1: Abstract Component

β

β’

α , d



Step 2: Interface Variable & Predicates



Step 2: Interface Variable & Predicates



Step 3: Internal Interface Relations

Fixed Priority Scheduling



Applications

• Interface-Based Design of RT Systems– Find minimum processor speed for complex systems with mixed

hierarchical scheduling.– Find optimal TDMA slot and cycle length allocations.– Specify maximum allowable input stream rates.– …

• Answering of design questions, e.g. resource dimensioning• On-Line Load Adaptation• On-Line Service Adaptation• On-Line Admission Tests• …



A Simple System with FP Scheduling...

L2

L1

CPU

T2

T1Load 1: p = 3, d = 6

Load 2: p = 6, d = 7

CPU: Fully Available

T1: WCET = 1

T2: WCET = 1



... and its Real-Time Interface Model

CPU

T2L2

T1L1

L2

L1

CPU

T2

T1



Schedulability Analysis

CPU

T2L2

T1L1

dA=1dG=6

dA=2dG=7



Applications



• Answering of design questions, e.g. resource dimensioning• On-Line Load Adaption• On-Line Service Adaption• On-Line Admission Tests• …



T1

Resource Dimensioning

CPU

T2L2

L1

1. Full CPU with min frequency

2. CPU with bounded delay

3. CPU with TDMA, and others

Different options:



Applications



• Answering of design questions, e.g. resource dimensioning• On-Line Load Adaption• On-Line Service Adaption• On-Line Admission Tests• …



dA=3

On-Line Load Adaption (Burstiness)

CPU

T2L2

T1L1

dA=2dG=7

dA=1dG=6

1. Check2. Admit3. Update



dG=6

On-Line Load Adaption (Delay)

CPU

T2L2

T1L1

dA=3dG=7

dA=1


dG=2?



On-Line Service Adaption

CPU

T2L2

T1L1

dG=7

dA=1.25dG=2


dA=3

dA=1



Outline

• Real-Time Interfaces / Interface-Based Design

• IBD Case Study



A System with Complex Scheduling...

Full Processor

FP

T3T2

T4T1

EDF

T6T5

RM

T10T9T8T7

EDFSPS

DPS

10 Tasks- with jitter- with bursts- deadline = period- deadline < period- deadline > period

3 Scheduling Policies- Rate Monotonic- Earliest Deadline First- Fixed Priority

Hierarchical SchedulingStatic & Dynamic Polling Servers

Total Utilization: 98.5%



... and its Real-Time Interface Model

Service

FP

EDF

FP

T3

T2

T4

T1

EDFT6

T5

SPS

RMT7-T10

DPS




Service

FP

EDF

FP

T3

T2

T4

T1

EDFT6

T5

SPS

RMT7-T10

DPS

Implicit by Successful Composition!




Service

FP

EDF

FP

T3

T2

T4

T1

EDFT6

T5

SPS

RMT7-T10

DPS



System Adaption I: Burstiness of T2

Service

FP

EDF

FP

T3

T2

T4

T1

EDFT6

T5

SPS

RMT7-T10

DPS



System Adaption II: Deadline of T2

Service

FP

EDF

FP

T3

T2

T4

T1

EDFT6

T5

SPS

RMT7-T10

DPS



System Analysis Time

• < 1 second – Pentium Mobile 1.6 GHz– Matlab 7 SP2– RTC Toolbox

Swiss FederalInstitute of Technology


Thank you!


Nikolay [email protected]


Simon Perathoner

6. Comparison with other analysis approaches



Motivation

Abstractions

Benchmarks

Conclusions

Outline


System level performance analysis

T4

T3

T1T5

T2

CPU1

CPU2

CPU3

AND

I1

I2

O2

O1

Max.Bufferspace?

Max.CPU load?

Max.end-to-end

delay?


Formal analysis methods

T4

T3

T1T5

T2

CPU1

CPU2

CPU3

AND

I1

I2

O2

O1 Abstraction

Analysis

Performance values

Distributed system Abstraction 1

Analysis method 1

Abstraction 2

GPC GPC

GPC GPC

GPC GSC

TDMA

Analysis method 2

Abstraction 3

Analysis method 3


Motivating questions

What is the influence of the different models onthe analysis accuracy ?

Evaluation and comparison of abstractions is needed !

Does abstraction matter ?

Which abstraction is best suited for a given system ?


How can we compare different abstractions ?

scope

usability

simpleexact

compositional

easy to use

tool supportstepwise refinement

efficientimplementation

learning curve

scalability

accuracy analysis time

holistic

performance metricsmodeling effort

modular

correctness

Method 1

Method 2

T4

T3

T1T5

T2

CPU1

CPU2

CPU3

AND

I1

I2

O2

O1


What makes a direct comparison difficult? Many aspects can not be quantified

A

B

C

D

Models cover different scenarios:


Intention

Compare models and methods that analyze the timing properties of distributed systems:

SymTA/S [Richter et al.]

MPA-RTC [Thiele et al.]

MAST [González Harbour et al.]

Timed automata based analysis [Yi et al.]

…


Leiden Workshop on Distributed Embedded Systems: http://www.tik.ee.ethz.ch/~leiden05/

Define a set of benchmark examples that cover common area

Define benchmark examples that show the power of each method

SymTA/S

MAST

TA

MPA

Approach


Expected (long term) results

Understand the modeling power of different methods

Understand the relation between models and analysis accuracy

Improve methods by combining ideas and abstractions


Contributions

We define a set of benchmark systems aimed at the evaluation of performance analysis techniques

We apply different analysis methods to the benchmark systems and compare the results obtained in terms of accuracy and analysis times

We point out several analysis difficulties and investigate the causes for deviating results


Motivation

Abstractions

Benchmarks

Conclusions

Outline


Abstraction 1 - Holistic schedulingBasic concept: extend concepts of classical scheduling

theory to distributed systems

Holistic scheduling

FP CPUs + TDMA bus

[Tindell et al.]1994

FP + datadependencies

[Yen et al.]1995

FP + control dependencies

[Pop et al.]2000

CAN[Tindell et al.]

1995

Mixed TT/ETsystems

[Pop et al.]2002

EDF offset based [González et al.]

2003

. . .


Holistic scheduling – MAST tool

MAST - The Modeling and Analysis Suite for Real-Time Applications [González Harbour et al.]

SystemTXT

SystemTXT

ResultsTXT

ResultsTXT


Abstraction 2 – The SymTA/S approach

Basic concept: Application of classical scheduling techniques at resource level and propagation of results to next component

Problem: The local analysis techniques require the input event streams to fit given standard event models

Solution: Use appropriate interfaces: EMIFs & EAFs

EMIF / EAF


SymTA/S – Tool


Abstraction 3 – MPA-RTC

t

events

events

Δ

αlαu

t

availability

βu

βlservice

Δ

Load model Service model

Arrival curves Service curves


Abstraction 3 – MPA-RTC

[αl, αu]

[βl, βu]

[βl’, βu’]

[αl’, αu’]

GPC


Abstraction 4 - TA based performance analysis

Verification of performance properties by model checking (UPPAAL)

fixed priorityscheduling

periodic streamExact performance values


Motivation

Abstractions

Benchmarks

Conclusions

Outline


Benchmarks

Pay burst only once

Complex activation pattern

Variable feedback

Cyclic dependencies

AND/OR task activation

Intra-context information

Workload correlation

Data dependencies


Benchmark 1 – Complex activation pattern

WCRT T3 ?

period

C = 35

C = 2

C = 12

C = 4

(FP)

(FP)

periodicP = 60

periodicP = 5

periodic


Benchmark 1 – Analysis results


Benchmark 1 – Result interpretation PI3 = 65 ms


Benchmark 1 – Worst case Delay I2-O2


Benchmark 2 – Variable feedback

T1

CPU1

T2

T3

T4

CPU2

I1

I2

O1

O2

Maxdelay ?

Exec. time C

C = 2

C = 2

C = 1(FP)

(FP)periodicP = 100

periodicP = 5


Benchmark 2 – Analysis results

T1

CPU1

T2

T3

T4

CPU2

I1

I2

O1

O2


Benchmark 3 – Cyclic dependencies

I1 T1

CPU1

T2

CPU2

O1 T3

Max delay ?

jitter

C = 1

C = 4

C = 4

(FP)

periodicwith burstP = 10


Benchmark 3 – Analysis resultsScenario 1: priority T1 = high

priority T3 = lowI1 T1

CPU1

T2

CPU2

O1 T3


Benchmark 3 – Analysis resultsScenario 2: priority T1 = low

priority T3 = high I1 T1

CPU1

T2

CPU2

O1 T3


Analysis times [s]

< 0.5< 0.5< 0.5

0.50.50.5

0.50.50.5

< 0.5< 0.5< 0.5

1.01.01.0

minmedmax

Simulation

< 0.5< 0.5< 0.5

< 0.5< 0.5

5.5

< 0.51.0

52.0

< 0.5< 0.5< 0.5

18.034.560.5

minmedmax

Timed aut.

< 0.5< 0.5< 0.5

< 0.5< 0.5< 0.5

< 0.5< 0.5< 0.5

< 0.5< 0.5< 0.5

---

minmedmax

MAST

0.060.090.31

0.030.340.80

0.030.060.09

0.030.050.23

0.050.091.50

minmedmax

SymTA/S

0.030.050.20

0.040.150.30

0.010.010.04

0.030.040.08

0.601.06

19.72

minmedmax

MPA-RTC

B4B3 (sc.2)B3 (sc.1)B2B1


Motivation

Abstractions

Benchmarks

Conclusions

Outline


ConclusionsThe analysis accuracy and the analysis time depend highlyon the specific system characteristics

None of the analysis methods performed best in all benchmarks

The analysis results of the different approaches are remarkable different even for apparently basic systems

The choice of an appropriate analysis abstraction matters

The problem to provide accurate performance predictions for general systems is still far from solved


DiscussionApproximation of complex event streams with standard event models can lead to poor performance predictions atlocal level

Holistic approaches better in the presence of correlationsamong task activations (e.g. data dependencies)

Cyclic dependencies represent a serious pitfall for the accuracy of compositional analysis methods

Holistic methods less appropriate for timing properties referred to the actual release time of an event within a large jitter interval


Thank you!

Simon Perathoner

[email protected]

Documents

Modular Performance Analysis with Real-Time Calculus · Computer Engineering and Networks Laboratory (TIK) 2 Presentation overview Introduction to System Level Performance Analysis