Execution architecture concepts

Transcription

1 by Gerrit Muller Buskerud University College Abstract The execution architecture determines largely the realtime and performance behavior 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 recommendations are given such as separation of concerns, understandability and granularity. The use of budgets for design and feedback is discussed. hard real time systems should be explainable with a few A4 diagrams reasoning must to combine or be possible not to combine? Distribution This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: preliminary draft limited use of tasks, threads, priorities overview is based on understanding many (critical) details simulation: additional means if declared indispensable this is often a symptom of poor models complex reality; many details, many relations simulation simple is better

2 Execution Architecture dead lines timing, throughput requirements other architecture views receive functional model demux process display store hardware CPU DSP RAM tuner drive input input execution architecture Map input repository structure play UI toolkit menu foundation classes queue list Applications zap DCT tuner txt processing hardware abstraction DVD drive process process task task task thread thread thread thread process thread interrupt handlers execution architecture issues: concurrency scheduling synchronisation mutual exclusion priorities granularity 2 Gerrit Muller CVexecutionArchitecture

3 Fuzzy customer view on real time hard real time soft real time disastrous failure dissatisfaction human safety device safety loss of functionality limited throughput waiting time loss of information loss of eye hand coordination 3 Gerrit Muller EAChardVsSoft

4 Smartening requirements Limited set of hard real time cases Precise form of the distribution is not important. freq Be aware of systematic effects 20 ms time No exception allowed Worst case must fit Well defined set of performance critical cases freq Typical within desired time, limited exceptions allowed. 90% time 200 ms 500 ms Exceptions may not result in functional failure 4 Gerrit Muller EACsmarteningRequirements

5 Latency telephone long distance connection telephone bla bla bla reaction perceived delay connection latency connection latency speak listen bla bla bla reaction speak listen bla bla bla reaction time 5 Gerrit Muller EAClatency

6 Response Time new channel P+ P- zap total response time zap repetition remote control zap visual feedback open for next respons new channel visual feedback time time 6 Gerrit Muller EACresponseTime

7 Throughput speakers tuner tuner pip processing throughput: + processing steps/frame + frames/second + concurrent streams screen TV 7 Gerrit Muller EACthroughput

8 Gross versus Nett bus bandwidth, processor load [memory usage] useful macroscopic views, be aware of microscopic behavior gross nett margin loss = not schedulable overhead bus, OS, scheduling function 4 function 3 function 2 depends on design depends strongly on granularity application overhead is still in this "nett" number function 1 8 Gerrit Muller EACbrutoVsNetto

9 Design recommendations separation of concerns soft Real Time process as unit of execution clear single demarcation between hard and soft decoupling queues or buffers minimize influence HW HW HW minimal shared resources hard Real Time separation performance cost manage tension explicit 9 Gerrit Muller EACseparation

10 Design recommendations understandability hard real time systems should be explainable with a few A4 diagrams to combine or not to combine? reasoning must be possible limited use of tasks, threads, priorities overview is based on understanding many (critical) details complex reality; many details, many relations simulation simulation: additional means if declared indispensable this is often a symptom of poor models simple is better 10 Gerrit Muller EACunderstandability

11 Granularity considerations unit of buffering == or <> unit of synchronization == or <> unit of processing == or <> unit of I/O video frame video line pixel fine grain: flexible high overhead coarse grain: rigid low overhead 11 Gerrit Muller EACgranularity

12 Design patterns synchronous safety critical, reliable, subsystems very low overhead predictable understandable works best in total separation does not work for multiple rhythms timer based thread based Asynchronous applications and services separation of timing concerns sharing of resources (no wait) poor understanding of concurrency danger of high overhead interrupt based regular rhythm; e.g.monitorhwstatus,updatetime,statusdisplay low "tunable" overhead understandable fast rhythms significant overhead I/O and HW events datavailable,displayframesync separation of timing concerns definition of interrupts determines: overhead, understandability 12 Gerrit Muller EACdesignPatterns

13 Synchronous design HW input for t n input for t n+1 input for t n+2 input for t n+3 SW calculate t n-1 calculate t n calculate t n+1 calculate t n+2 HW execute t n-2 execute t n-1 execute t n execute t n+1 clk setting t n+1 setting t n double buffer: full decoupling of calculation and execution HW 13 Gerrit Muller EACsynchronousDesign

14 Actual timing on logarithmic scale application needs light travels 1 cm 100Hz video pixel time 100Hz video line 100 Hz TV frame human eye eye-hand co-ordination (ps) (ns) ( s) (ms) (s) human reaction time human 1 st irritation threshold human 2 nd irritation threshold FO4 inverter delay cycle 2 GHz CPU pure context switch zero message transfer appl level message exchange appl level function response from low level to high level processing times from low to high level storage/network DRAM cycle time DRAM latency 1 byte transfer fast ethernet 1 package transfer fast ethernet Disk seek appl level network message exchange appl level function response 14 Gerrit Muller RVtimeAxis

15 Typical micro benchmarks for timing aspects database infrequent operations, often time-intensive start session finish session often repeated operations perform transaction query network, I/O high level construction low level construction basic programming OS HW open connection close connection component creation component destruction object creation object destruction memory allocation memory free task, thread creation power up, power down boot transfer data method invocation same scope other context method invocation function call loop overhead basic operations (add, mul, load, store) task switch interrupt response cache flush low level data transfer 15 Gerrit Muller RVuTimingBenchmarks

16 The transfer time as function of blocksize time worst case t overhead optimal block-size -1 rate block size 16 Gerrit Muller RVparametrizedTransferRate

17 Example of a memory budget memory budget in Mbytes code obj data bulk data total 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 Gerrit Muller RVmemoryBudgetTable

18 Complicating factors and measures complications 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 measures considered margin explicit behavior architecture rules monitoring, logging pool management feedback to architect flipover simulation 18 Gerrit Muller EACcomplicationsMeasures