A QoS-aware CCM for DRE System Development Nanbor Wang Tech-X Corporation 5561 Arapahoe Ave., Suite A Boulder, CO 33 Chris Gill Dept. of Computer Science and Engineering Washington University One Brookings Drive St. Louis, MO 6313 nanbor@txcorp.com cdgill@cse.wustl.edu OMG Real-time and Embedded Systems Workshop Reston, VA, USA July 13, 24 This work was supported in part by the DARPA PCES program, contracts F33615--C-348 and F33615-3-C-4111
Goal: How Can We Combine RT-CORBA and CCM? Central Data Store Real-Time Component Repository Compose Chicago Data Center Component Assembly Flight Scheduling Middleware Bus Deploy Field Radar Control System Airport Approach Control Real-Time Flight Status Bulletin Board Client WWW Bringing component-oriented software development paradigm into DRE application domain System Development Deployment & Configuration Metadata Deployment & Configuration Mechanism Flight Scheduling Processing Container Middleware Framework Component Server Web Gateway Component Container Meta-programming Real-time CORBA aspects in CIAO
Problem: Current CCM Fails to Address DRE QoS QoS-enabled CCM CCM + RT CORBA Running an RT ORB beneath CCM doesn t make it a QoSenabled CCM implementation Conventional CCM has few mechanisms to specify and enforce QoS policies Especially for DRE systems E.g., deadline, rate, priority Consequences: Tight coupling between component implementations and QoS enforcement Coupling between components that QoS aspects cross-cut Difficulty in reusing existing components for different QoS contexts
Solution: Compose Real-Time Aspects in CCM Real-time behaviors specification Positioning Unit RateGen GPS Pulse Refresh Ready Low Priority Instrument Cluster GUIDisplay Refresh Rate MyLocation GPSLocation Compose RateGen Pulse Collision Radar Refresh Ready High Priority LEDDisplay Refresh Rate MyLocation GPSLocation A novel architecture to integrate component meta-programming and systemic aspects, e.g., extending CCM atop RT-CORBA features Makes real-time behaviors an integral part of the framework so they can be composed into DRE applications
Challenge: Compose Systemic Aspects Effectively Context: Need to enable consistent assembly of systemic aspects Need to configure QoS aspects at a variety of granularities Configuration information is available at different points in the application lifecycle Problem: Programming QoS aspects imperatively is tedious, error prone, and insufficiently customizable Positioning Unit RateGen GPS Pulse Refresh Ready MyLocation Rate RateGen Pulse Rate Collision Radar Refresh MyLocation Ready Low Priority High Priority Instrument Cluster GUIDisplay Refresh GPSLocation LEDDisplay Refresh GPSLocation
Solution: Metadata for Real-time Aspects <!ELEMENT rtcad_ext ( rtresources?, rtpolicyset+)> <!ELEMENT rtresources (threadpool threadpoolwithlanes connectionbands)* > <!ELEMENT rtpolicyset (priority_model_policy, threadpool_policy, banded_connection_policy)+ > Real-time extension XML descriptors (ext. filename:.rtd) Associated at assembly stage Used by deployment stage Declaratively specify: Resources for ORBs Consistent groups of policies for real-time behaviors applied in containers Encapsulate all RT policies and resources in one file: Resources global to a component server Sets of policies an instance of component requires
Challenge: Address Platform Diversity Assembly Deployer 7. return the assembly id Assembly Manager 3b. Return container reference VxWorks 1. Deploy assembly x.cad 3. create container 4. Install component Impl: compuuid 4d. Return home reference 5. create component instance 5b. Return component reference Deployment Target Host 2. create component server 2b. Return component server reference Component Server Container CCMHome Linux 2a. create 4a. Query impluuid 4b. Return impl pathname CIAO_Daemon Server Activator Component Implementation Manager Enterprise Component Context: CCM enables building and configuring distributed applications across network of heterogeneous platforms Real-time systemic behaviors require special configurations to the component server Problems: Different configurations are needed to support the same behaviors Different mechanisms are available
Solution: Separate Logical & Physical Configurations Create server with MultiEndPoints configuration Document the intentions but defer the decision of actual strategies to some later point Specify only names of configurations initially Select actual configuration upon deployment to a target platform Similar approach is used for configuration of deployment topology
Empirically Evaluating Representative Examples Experiments: Based on representative avionic application Comparison between same test program built using CIAO vs. TAO Throughput Latency Priority enforcement Verify that CIAO can effect desired real-time behaviors Based on canonical RT-CORBA tests for TAO Evaluate cost of CCM layer relative to underlying ORB middleware
C A 78 911112 123456 7x 1x 8x 2x 9x 3x A 1x 4x 11x 5x 12x 6x 7x 1x 8x 2x 9x 3x B 1x 4x 11x 5x 12x 6x QoS-aware CCM for DRE System Development Experiment Configurations Ethernet Linux testbed Two 2. Ghz Pentium-4 boxes and two 2.53 Ghz Pentium-4 boxes Most experiments used 2.8 Ghz-pair to execute and 2.53 Ghz-pair for deployment KURT-Linux 2.4.18 CIAO.3.5 / TAO 1.3.5 / ACE 5.3.5 All tests compiled with highest optimization option (-O3) All tests run with SCHED_FIFO scheduling policy
Throughput (calls/sec) 1 9 7 5 3 TAO + RT-ORB 842 QoS-aware CCM for DRE System Development Throughput & Latency with RT Features Enabled CIAO + RT Component Server 817 (µs) 1 12 1 2 Mean 118.9 122.9 Standard Deviation (µs) 1 12 1 2 99% 123 127 Maximum 2 1 2. 1.5 1.38 1.58 25 2 182 219 Slightly higher throughput loss (3.7%) and corresponding latency increase (3.4%) Similarly CIAO doesn t affect the jitter based on std-dev, 99% case, or maximum latency 25 2 15 1 5 (µs) 1..5. TAO RT-TAO (µs) 25 2 15 1 5 15 1 5 CIAO RT-CIAO
Results and Analysis Separate Threadpools 25 Hz (Low Prio) 5 Hz (Mid Prio) 75 Hz (High Prio) Throughputs (calls/sec) 7 5 3 2 1 2 RMS 7 Work Load 1 12 1 1 1 2 22 2 2 2 25 Hz (High Prio) 5 Hz (Mid Prio) 75 Hz (Low Prio) 3 32 3 RMS lower rate (lower priority) controller-worker threads yield to the higher priority threads Anti-RMS higher rate (lower priority) controller-worker threads yield to the higher priority threads The real-time systemic behaviors are effective Throughputs (calls/sec) 5 3 2 1 2 1 Anti-RMS 12 1 1 1 2 22 Work Load 2 2 2 3 32 3 3 3
Results and Analysis Shared Threadpools 25 Hz (Low Prio) 5 Hz (Mid Prio) 75 Hz (High Prio) Throughputs (calls/sec) 7 5 3 2 1 2 RMS Throughputs (calls/sec) 7 5 3 2 1 2 1 Anti-RMS 1 12 1 12 1 1 1 1 1 2 Work Amounts 2 22 Work Amounts 22 2 2 25 Hz (High Prio) 5 Hz (Mid Prio) 75 Hz (Low Prio) 2 2 2 3 32 3 3 3 2 3 32 RMS lower rate (lower priority) controller-worker threads yield to the higher priority threads Anti-RMS higher rate (lower priority) controller-worker threads yield to the higher priority threads The real-time systemic behaviors are effective by using a different strategy
Concluding Remarks Combining CCM+RT aspects overcomes limitations of Conventional DRE middleware Conventional component middleware Approach provides a novel and effective meta-programming architecture for QoS aspects in DRE component middleware Declarative composition of policies/mechanisms at fine granularity throughout the DRE system lifecycle Empirical studies show temporal cost of flexibility can be low, compared to conventional RT-CORBA middleware Profiling and implementation experience indicate CCM+RT aspect programming model helps DRE system development Simplifies application development/assembly/deployment Allows late-lifecycle performance optimizations
Distributed Scientific Computing Environment Composing distributed scientific computation applications using Lightweight CCM Composing scientific component using Common Component Architecture (CCA) Incorporate CCA run-time environment in CCM component implementations Incorporate legacy scientific code (FORTRAN, C, etc.) Extra-functional aspects, such as, Parallelism Streaming of data Future Work