1. Christopher Gill and Nanbor Wang Department of Computer Science and Engineering Washington University, St. Louis {cdgill,nanbor}@cse.wustl.edu Monday May 19, 2003 Exploiting CCM Lifecycle Stages for BoldStroke Component Configuration with CIAO CCM Workshop, Kansas State University, Manhattan, Kansas Work supported by DARPA contract F33615-00-C-3048 (WU PCES subcontract from Boeing)

2. Chris Gill and Nanbor Wang BoldStroke Component Configuration in CIAO Washington University, St. Louis Component Configuration Lifecycle Two distinct “planes” of a system –Functional aspects Interfaces are implemented Syntactic match for call/interface –Extra-functional QoS aspects Caller/called available rates match Total resource allocation is feasible Utilization is tuned Three system config phases –Component packaging –Application assembly –Application deployment Analysis needed at each stage –Functional/extra-functional aspects –Some info added/changed at each –May leave some decisions for later Properties DeploymentT ool Assembly Archive.aar (ZIP) Assembly/ Packaging Tool Component Package Component Package Component Package Port Connections Instance Creation

3. Chris Gill and Nanbor Wang BoldStroke Component Configuration in CIAO Washington University, St. Louis Component Packaging Check Functional Aspects –Are all offered ports implemented by executor? Check QoS Aspects –Are modes specified? –Are intra-component port dependencies specified? –Are available rates specified for each port in each mode? Might allow to specify { } (empty) –Are calibrated execution times specified for each mode? (e.g., WCET ) Attributes Event Sinks Facets Receptacles Component Reference Offered Ports Required Ports Event Sources Component Executor

4. Chris Gill and Nanbor Wang BoldStroke Component Configuration in CIAO Washington University, St. Louis Application Assembly Component Server RateGenerator HiResGPS CockpitDisplay Check Functional Aspects –Are inter-component port dependencies specified? –Do signatures match between required and offered ports along each dependency? Check QoS Aspects –Can sets of available rates be derived for each port in each mode? Using simple rate propagation to fill in empty sets –Do sets of rates match? Narrow to rate set intersection

5. Chris Gill and Nanbor Wang BoldStroke Component Configuration in CIAO Washington University, St. Louis Application Deployment Check Functional Aspects –Are OS/middleware services bound and available? Check QoS Aspects –Is CPU speed known? Recalibrate WCET values –Is there a feasible resource allocation (at some rates?) –Can we optimize feasible configurations of rates? E.g., FAIR, CB-FAIR (WSOA) E.g., feedback control U=.90 RateGenerator HiResGPS CockpitDisplay WayFast TM Processor

6. Chris Gill and Nanbor Wang BoldStroke Component Configuration in CIAO Washington University, St. Louis BoldStroke Configuration Example: Packaging Config Phase Available Rates (in Hz)WCET (in msec) PackagingRateGenerator: {1,5,10,20,40} HiResGPS: {x | x < 40} CockpitDisplay: {y | y ≥ 10} RateGenerator:1@400Hz HiResGPS: 40@400Hz CockpitDisplay: 5@400Hz Info from that component only Most General Constraints

7. Chris Gill and Nanbor Wang BoldStroke Component Configuration in CIAO Washington University, St. Louis BoldStroke Configuration Example: Assembly Config Phase Available Rates (in Hz)WCET (in msec) PackagingRateGenerator: {1,5,10,20,40} HiResGPS: {x | x < 40} CockpitDisplay: {y | y ≥ 10} RateGenerator:1@400Hz HiResGPS: 40@400Hz CockpitDisplay: 5@400Hz Assembly RateGenerator → HiResGPS → CockpitDisplay: {10,20} RateGenerator:1@400Hz HiResGPS: 40@400Hz CockpitDisplay: 5@400Hz Composite info (still partially specified) Intersections of constraints from individual components

8. Chris Gill and Nanbor Wang BoldStroke Component Configuration in CIAO Washington University, St. Louis BoldStroke Configuration Example: Deployment Config Phase Available Rates (in Hz)WCET (in msec) PackagingRateGenerator: {1,5,10,20,40} HiResGPS: {x | x < 40} CockpitDisplay: {y | y ≥ 10} RateGenerator:1@400Hz HiResGPS: 40@400Hz CockpitDisplay: 5@400Hz Assembly RateGenerator → HiResGPS → CockpitDisplay: {10,20} RateGenerator:1@400Hz HiResGPS: 40@400Hz CockpitDisplay: 5@400Hz Deployment (200MHz CPU) RateGenerator → HiResGPS → CockpitDisplay: 10 RateGenerator:2 HiResGPS: 80 CockpitDisplay: 10 Fully specified Info Bound constraints (constants)

9. Chris Gill and Nanbor Wang BoldStroke Component Configuration in CIAO Washington University, St. Louis BoldStroke Configuration Example: Tuning Config Phase Available Rates (in Hz)WCET (in msec) PackagingRateGenerator: {1,5,10,20,40} HiResGPS: {x | x < 40} CockpitDisplay: {y | y ≥ 10} RateGenerator:1@400Hz HiResGPS: 40@400Hz CockpitDisplay: 5@400Hz Assembly RateGenerator → HiResGPS → CockpitDisplay : {10,20} RateGenerator:1@400Hz HiResGPS: 40@400Hz CockpitDisplay: 5@400Hz Deployment (200MHz CPU) RateGenerator → HiResGPS → CockpitDisplay : 10 (not optimal on 400Hz CPU) RateGenerator:2 HiResGPS: 80 CockpitDisplay: 10 Deployment (400MHz CPU) RateGenerator → HiResGPS → CockpitDisplay : 20 (not feasible on 200Hz CPU) RateGenerator:1 HiResGPS: 40 CockpitDisplay: 5 Feasible for 200MHz CPU Tuned for 400MHz CPU

10. Chris Gill and Nanbor Wang BoldStroke Component Configuration in CIAO Washington University, St. Louis Summary CIAO makes the QoS aspects of BoldStroke components first-class elements in the CCM programming model –Just as functional aspects are first-class in “plain-old” CCM –Ensures QoS correctness across applications & platforms –Supports composition of QoS (as well as functional) aspects –Allows custom optimization for performance and control Several configuration phases in the system lifecycle –Each with more information and more constraints –When a value is bound is crucial, parameterization matters If several alternatives are acceptable, need tuning metrics –Successive constraint composition/resolution –Resulting set of alternatives may have > 1 element: “conflict set” –Use additional optimizations/control/tuning to choose one

11. Chris Gill and Nanbor Wang BoldStroke Component Configuration in CIAO Washington University, St. Louis Looking Ahead Next steps: Cadena on CIAO, PI meeting June 4-6 –What CIAO features are missing, or need revision? Partial evaluation and refinement are fundamental –CIAO can provide hooks at each configuration stage –Modeling tools may insert QoS constraints & variables to be refined E.g., calibrated execution times based on CPU speed Static role of modeling tools in this example is clear –Specify variables, range bounds, initial values –Load and check CIAO XML specification at each stage –Update and store CIAO XML specification for next stage Overall run-time architecture is less clear –Do modeling tools provide run-time checkers? –How do they interface with schedulers, other services? –With epochs of adaptation, is configuration lifecycle a spiral?