RT Reading Group Meeting
06/27/2002
Veljko Krunic
Agenda
Introduction
 Motivation of system
 System components

– Gryphon
– RT-PCIP and EPA
– DQM
Real-Time and OO
 Q&A

Introduction

Motivation for presenting this papers
– To understand integrated system
– To understand components on high level

Papers
– Are survey of all individual work
– Present “Big picture”
This presentation is continuation of Sam’s
presentation
 Discussion of OO in context of Real Time

Motivation

Multiperson distributed virtual environment
– Supports multiperson communication
– Plus domain specific tools

World consists of
– Objects
– Avatars

Form of telepresence
Motivation (Cont)

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
Gryphon

Distributed object manager
– Caching
– Cache coherence
– Works in cooperation with applications

Object types
–
–
–
–
Private-local
Shared-local
Shared-nonlocal
Global
Object Location
Constrained by access times
 Caching policy

– Refreshment frequency
– Bandwidth requirements
Known best by application
 Application negotiates

– Consistency update policy
– Object location
Gryphon and CORBA

CORBA
– Distributed object access & RPC
– Parameter marshalling
– ORB implements coordination

Gryphon compared to
– Centralized object manager
– ORB centralized CORBA
– ORB distributed CORBA

Gryphon provides significant improvements
RT-PCIP

Device-to-device pipeline architecture
– Standardized source and sink
– Filters could be inserted

EPA
– Dynamic priority computation in overloaded system

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
Process info are based on triples
– Execution level
– Resource
– Benefit

Plus
– Maximum benefit
– Maximum CPU usage
– Number of execution levels
Resource Allocation Policies

Distributed
– Missing deadline changes execution level of
that process

Fair
– Missing deadline reduces level of application
using most of CPU (even) or that has lowest
benefit/CPU ratio (proportional)
Resource Allocation Policies

Distributed
– Missing deadline changes execution level of
that process

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
–
–
–
–

Maximize overall user benefit
Good for initial allocations
Causes a lot of fluctuation
Artificial parameter added to tame fluctuations
Hybrid
– Optimal for initial allocations
– Different algorithms from that point on
DQM Limitations

User space implementation
– Based on cooperation from applications
– Could not control rogue applications

What if application estimates are wrong
– Fluctuations and resonance

Requires dynamic refinement
– Based on weight factor
– What about more complicated models of load?
OO and Hard Real Time
Subject of personal interest
 Discussion of OO

– Design by contract
– Preconditions, postconditions and invariance
– Combination with Hard Real Time

Based on some discussions and article in
DDJ
Design by Contract
OO technique invented by Bertrand Meyer
 Eiffel
 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)
– Precondition x > 0
– Postcondition: x == y*y

Exception is thrown if precondition or
postcondition is violated
Design by Contract and RT






Based on the article in DDJ
Extend preconditions and postcondition on
timings
Automatic watchdog per thread
Could be done in C/C++
Similar work done by Adam
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
 Presentation I made in the JD Edwards

Summary
High level system description
 Summary of individual works
 Some OO and distributed programming mix

Q&A