Execution architecture concepts - · PDF fileExecution architecture concepts by Gerrit Muller Buskerud University College e-mail: [email protected] Abstract The execution architecture

Execution architecture conceptsby Gerrit Muller Buskerud University College

e-mail: [email protected]

Abstract

The execution architecture determines largely the realtime and performancebehavior of a system. Hard real time is characterized as ”missing a deadline”will result in system failure, while soft real time will result ”only” in dissatisfaction.An incremental design approach is described. Concepts such as latency,response time and throughput are illustrated. Design considerations and recom-mendations are given such as separation of concerns, understandability andgranularity. The use of budgets for design and feedback is discussed.

Distribution

This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.

October 20, 2017status: preliminarydraftversion: 1.1

complex reality;

many details,

many relations

limited use of tasks,

threads, priorities

to combine or

not to combine?

simple is better

hard real time systems

should be explainable

with a few A4 diagrams

reasoning must

be possible

simulation

simulation: additional means

if declared indispensable this is

often a symptom of poor models

overview is based on

understanding many

(critical) details

Execution Architecture

other architecture

views

execution

architecture

functional

model

process

display

receive demux

store

Map

process

task

threadthreadthread

process

task

threadthreadthread

process

taskthreadthreadthread

interrupt

handlersinput

hardware

tuner drive

CPU DSP RAM

input

repository

structure

queue

DCTmenu

txt

tuner

foundation

classes

hardware

abstraction

list DVD drive

UI toolkit processing

Applicationsplay zap

input

dead lines

timing, throughput

requirements

execution architecture

issues:

concurrency

scheduling

synchronisation

mutual exclusion

priorities

granularity

Execution architecture concepts2 Gerrit Muller

version: 1.1October 20, 2017

CVexecutionArchitecture

Fuzzy customer view on real time

hard real time

disastrous

failure dissatisfaction

human

safety

device

safety

loss of

information

loss of

functionality

limited

throughput

loss of

eye hand

coordination

waiting

time

soft real time



EAChardVsSoft

Smartening requirements

Limited set of hard real time cases

time

freq

20 ms

Well defined set of performance critical cases

time

freq

200 ms 500 ms

90%

Precise form of the distribution

is not important.

Be aware of systematic effects

No exception allowed

Worst case must fit

Typical within desired time,

limited exceptions allowed.

Exceptions may not result in

functional failure



EACsmarteningRequirements

Latency

bla bla bla

telephone telephone

reaction

long distance connection

time

bla bla bla

reactionbla bla bla

reaction

connection

latency

perceived delay

connection

latency

speaklisten

speaklisten



EAClatency

Response Time

P+

P-

remote

control

time

zap

new

channel

total response time

visual

feedback

visual feedback time

zap

new

channel

open for next

respons

zap repetition



EACresponseTime

Throughput

processing

throughput:

+ processing steps/frame

+ frames/second

+ concurrent streams

screen

tuner

speakers

pip

tuner

TV



EACthroughput

Gross versus Nett

bus bandwidth, processor load [memory usage]useful macroscopic views, be aware of microscopic behavior

function 1

overheadbus, OS,

scheduling

loss = not schedulable

depends strongly on granularity

depends on design

margin

function 4

function 3

function 2net

t

gro

ss

application overhead is still

in this "nett" number


version: 1.1October 20, 2017EACbrutoVsNetto

Design recommendations separation of concerns

soft Real Time

hard Real Time

HW HW HW

minimize

influencedecoupling

minimal

shared

resources cost

performance

separation

manage

tension

explicit

queues or buffers

clear single demarcation

between hard and soft

process as unit of execution



EACseparation

Design recommendations understandability

complex reality;

many details,

many relations

limited use of tasks,

threads, priorities

to combine or

not to combine?

simple is better

hard real time systems

should be explainable

with a few A4 diagrams

reasoning must

be possible

simulation

simulation: additional means

if declared indispensable this is

often a symptom of poor models

overview is based on

understanding many

(critical) details



EACunderstandability

Granularity considerations

video frame

video line

pixel

unit of

synchronization

unit of

buffering

==

or

<>

==

or

<>

unit of

processing

==

or

<>

unit of

I/O

fine grain:

flexible

high overhead

coarse grain:

rigid

low overhead



EACgranularity

Design patterns

synchronous

very low overhead

predictable

understandable

works best in total separation

does not work for multiple rhythms

timer based

low "tunable" overhead

understandable

regular rhythm;e.g. monitor HW status, update time, status display

safety critical, reliable, subsystems

fast rhythms significant overhead

interrupt based

separation of timing concerns

I/O and HW eventsdata available, display frame sync

definition of interrupts determines:

overhead, understandability

thread based

separation of timing concerns

sharing of resources (no wait)

Asynchronous applications and

services

poor understanding of concurrency

danger of high overhead



EACdesignPatterns

Synchronous design

execute tn-1 execute tn+1execute tn

input for tn+1 input for tn+2 input for tn+3

calculate tn calculate tn+2calculate tn+1

execute tn-2

input for tn

calculate tn-1

double buffer:

full decoupling of calculation and executionsetting tn

setting tn+1

HW

clk

HW

HW

SW



EACsynchronousDesign

Actual timing on logarithmic scale

Disk se

ek

hum

an 1st ir

ritat

ion

thre

shold

appl le

vel fun

ction

resp

onse

hum

an 2nd ir

ritat

ion

thre

shold

eye-

hand

co-

ordina

tion

1 pa

ckag

e tra

nsfe

r

fast e

ther

net

(ps)

10-12

(ns)

10-9

(s)

10-6

(ms)

10-3

(s)

1

cycle

2 GHz CPU

pure

con

text switc

h

DRAM

late

ncy

1 by

te tr

ansfer

fast e

ther

net

zero

mes

sage

tran

sfer

appl le

vel n

etwor

k

mes

sage

exc

hang

e

appl le

vel m

essa

ge

exch

ange

appl le

vel fun

ction

resp

onse

hum

an re

actio

n tim

e

hum

an e

ye

FO4

inve

rter d

elay

DRAM

cyc

le tim

e

100

Hz TV

fram

e

100H

z vide

o

pixe

l tim

e

100H

z vide

o lin

e

from

low level to high level

processing times

from low to high level

storage/network

application

needs

light

travels

1 cm



RVtimeAxis

Typical micro benchmarks for timing aspects

object creation

object destructionmethod invocation

component creation

component destruction

open connection

close connection

method invocationsame scope

other context

start session

finish session

perform transaction

query

transfer data

function call

loop overhead

basic operations (add, mul, load, store)

infrequent operations,

often time-intensive

often repeated

operations

database

network,

I/O

high level

construction

low level

construction

basic

programming

memory allocation

memory free

task, thread creationOS task switch

interrupt response

HW cache flush

low level data transfer

power up, power down

boot



RVuTimingBenchmarks

The transfer time as function of blocksize

tim

e

blocksize

worst case

optimal block-size

toverhead

rate-1



RVparametrizedTransferRate

Example of a memory budget

shared code

User Interface process

database server

print server

optical storage server

communication server

UNIX commands

compute server

system monitor

application SW total

UNIX Solaris 2.x

file cache

total

obj data

3.0

3.2

1.2

2.0

2.0

0.2

0.5

0.5

12.6

bulk data

12.0

3.0

9.0

1.0

4.0

0

6.0

0

35.0

code

11.0

0.3

0.3

0.3

0.3

0.3

0.3

0.3

0.3

13.4

total

11.0

15.3

6.5

10.5

3.3

6.3

0.5

6.8

0.8

61.0

10.0

3.0

74.0

memory budget in Mbytes



RVmemoryBudgetTable

Complicating factors and measures

cache

bus allocation

memory management

garbage collection

memory (buffer, storage) fragmentation

non preemptable OS activities

"hidden" dependencies (ie [dead]locks)

systematic "coincidences", avalanche triggers

instable response, performance

considered margin

explicit behavior

architecture rules

monitoring, logging

pool management

feedback to architect

flipover simulation

complications measures



EACcomplicationsMeasures

Documents

Execution architecture concepts - · PDF fileExecution architecture concepts by Gerrit Muller Buskerud University College e-mail: [email protected] Abstract The execution architecture