RT Reading Group Meeting 06/27/2002 Veljko Krunic

Agenda Introduction Introduction Motivation of system Motivation of system System components System components –Gryphon –RT-PCIP and EPA –DQM Real-Time and OO Real-Time and OO Q&A Q&A

Introduction Motivation for presenting this papers Motivation for presenting this papers –To understand integrated system –To understand components on high level Papers Papers –Are survey of all individual work –Present “Big picture” This presentation is continuation of Sam’s presentation This presentation is continuation of Sam’s presentation Discussion of OO in context of Real Time Discussion of OO in context of Real Time

Motivation Multiperson distributed virtual environment Multiperson distributed virtual environment –Supports multiperson communication –Plus domain specific tools World consists of World consists of –Objects –Avatars Form of telepresence Form of telepresence

Motivation (Cont) Presents challenges Presents challenges –Graphics rendering –Continues media –Distributed objects –Movement of large amount of data –Applications –Thread schedulability and resource management –Dynamic negotiations Integrates all previous work of all team members Integrates all previous work of all team members

Gryphon Distributed object manager Distributed object manager –Caching –Cache coherence –Works in cooperation with applications Object types Object types –Private-local –Shared-local –Shared-nonlocal –Global

Object Location Constrained by access times Constrained by access times Caching policy Caching policy –Refreshment frequency –Bandwidth requirements Known best by application Known best by application Application negotiates Application negotiates –Consistency update policy –Object location

Gryphon and CORBA CORBA CORBA –Distributed object access & RPC –Parameter marshalling –ORB implements coordination Gryphon compared to Gryphon compared to –Centralized object manager –ORB centralized CORBA –ORB distributed CORBA Gryphon provides significant improvements Gryphon provides significant improvements

RT-PCIP Device-to-device pipeline architecture Device-to-device pipeline architecture –Standardized source and sink –Filters could be inserted EPA EPA –Dynamic priority computation in overloaded system EPA is based on DM tests EPA is based on DM tests –Uses expected time with probability distribution –WCET is statistical problem here

Dynamic QoS Manager Framework for QoS guarantees among processes Framework for QoS guarantees among processes Process info are based on triples Process info are based on triples –Execution level –Resource –Benefit Plus Plus –Maximum benefit –Maximum CPU usage –Number of execution levels

Resource Allocation Policies Distributed Distributed –Missing deadline changes execution level of that process Fair Fair –Missing deadline reduces level of application using most of CPU (even) or that has lowest benefit/CPU ratio (proportional)

Resource Allocation Policies Distributed Distributed –Missing deadline changes execution level of that process Fair Fair –Missing deadline reduces level of »Application using most of CPU (even) »Application that has lowest benefit/CPU ratio (proportional)

Resource Allocation Policies (Cont) Optimal Optimal –Maximize overall user benefit –Good for initial allocations –Causes a lot of fluctuation –Artificial parameter added to tame fluctuations Hybrid Hybrid –Optimal for initial allocations –Different algorithms from that point on

DQM Limitations User space implementation User space implementation –Based on cooperation from applications –Could not control rogue applications What if application estimates are wrong What if application estimates are wrong –Fluctuations and resonance Requires dynamic refinement Requires dynamic refinement –Based on weight factor –What about more complicated models of load?

OO and Hard Real Time Subject of personal interest Subject of personal interest Discussion of OO Discussion of OO –Design by contract –Preconditions, postconditions and invariance –Combination with Hard Real Time Based on some discussions and article in DDJ Based on some discussions and article in DDJ

Design by Contract OO technique invented by Bertrand Meyer OO technique invented by Bertrand Meyer Eiffel Eiffel Each method operates with guarantees Each method operates with guarantees –Precondition – this must be guranteed before I am called –Postcondition – if preconditions are met, this is my guarantee –Invariance – object of this class always has this

Design by Contract (Cont) Example: y = sqrt(x) Example: y = sqrt(x) –Precondition x > 0 –Postcondition: x == y*y Exception is thrown if precondition or postcondition is violated Exception is thrown if precondition or postcondition is violated

Design by Contract and RT Based on the article in DDJ Based on the article in DDJ Extend preconditions and postcondition on timings Extend preconditions and postcondition on timings Automatic watchdog per thread Automatic watchdog per thread Could be done in C/C++ Could be done in C/C++ Similar work done by Adam Similar work done by Adam Limited timer resolution unless on scheduler level Limited timer resolution unless on scheduler level –Testing paradigm, not RT concept –Are there benefits in allowing thread to address exception in its context?

Some Techniques for Multiprogramming Quick summary Quick summary Presentation I made in the JD Edwards Presentation I made in the JD Edwards

Summary High level system description High level system description Summary of individual works Summary of individual works Some OO and distributed programming mix Some OO and distributed programming mix

Q&A