Power Aware Real-time Systems A joint project with profs Rami Melhem Bruce Childers Mootaz Elnozahy (IBM Austin) Trying to rope in Ahmed Amer Jose Brustoloni and everyone else And students Nevine Abougazaleh Cosmin Rusu Dakai Zhu Ramesh Mishra Namrata Rastogi Sameh Gobriel

Outline Introduction to real-time systems Introduction to power management Speed adjustment in frame-based systems Dynamic speed adjustment in multiprocessor environment Tradeoff between energy consumption and reliability Saving power in wireless networks

Hard RT systems Periodic Aperiodic (frame-based) preemptive non preemptive non preemptive uni-processor parallel processors Soft RT systems Real-time systems

REAL-TIME SYSTEMS Hard Real Time system guarantee deadlines To guarantee deadlines, we need to know worst case execution times Predictability: need to know if deadlines may be missed Soft Real Time system try to meet deadlines If a deadline is missed, there is a penalty Provides statistical guarantees (probabilistic analysis) Need to know the statistical distribution of execution times Applications: Safety critical systems, control and command systems, robotics, Communication, multimedia

n tasks with maximum computation times C i and periods T i, for i=1,…,n. Dynamic priority scheduling (high priority to the task with earlier deadline) All tasks will meet their deadlines if utilization is not more than 1. Task set utilization is percentage of CPU used by all tasks: This example: + C=2, T=4 C=3, T=7 Periodic, EDF scheduling

Outline Introduction to real-time systems Introduction to power management Speed adjustment in frame-based systems Dynamic speed adjustment in multiprocessor environment Tradeoff between energy consumption and reliability Saving power in wireless networks

Power Management Why & What: Power Management?  Battery operated: Laptop, PDA and Cell phone  Heating : complex Servers (multiprocessors)  Power Aware: maintain QoS, reduce energy How?  Power off un-used parts: LCD, disk for Laptop  Gracefully reduce the performance CPU: dynamic power P d = C ef *V dd 2 *f [Chandrakasan-1992, Burd-1996]  C ef : switch capacitance  V dd : supply voltage  f : processor frequency  linear related to V dd

Power Aware Scheduling T1T1 D f max time Static Power Management (SPM)  Static slack: uniformly slow all tasks [Weiser-1994, Yao-1995, Gruian-2000] T2T2 E Static Slack Energy f T1T1 T2T2 idle time T1T1 T2T2 T2T2 T1T1 0.6E time T1T1 T2T2 f max /2 E/4

Power Management T1T1 D f max time Dynamic Power Management (DPM)  Dynamic slack: non-worst execution 10% [Ernst-1994]  DPM: [Krishna-2000, Kumar-2000, Pillai-2001, Shin-2001] T1T1 T2T2 T2T2 f max /2 Static Slack idle E E/4 time T1T1 T2T2 f max /3 0.12E time T1T1 f max /2 Dynamic Slack Multi-Processor  SPM: length of schedule over deadline  DPM ???

Outline Introduction to real-time systems Introduction to power management Speed adjustment in frame-based systems Dynamic speed adjustment in multiprocessor environment Tradeoff between energy consumption and reliability Saving power in wireless networks

time S max S min Select the speed based on worst-case execution time,WCET, and deadline CPU speed time deadline S max S min WCET Speed adjustment in frame-based systems Assumption: all tasks have the same deadline. Static speed adjustment

Dynamic Speed adjustment techniques for linear code time WCET ACET Speed adjustment based on remaining WCET Note: a task very rarely consumes its estimated worst case execution time.

Dynamic Speed adjustment techniques for linear code time Remaining WCET Remaining time Speed adjustment based on remaining WCET

Dynamic Speed adjustment techniques for linear code time Remaining WCET Remaining time Speed adjustment based on remaining WCET

Dynamic Speed adjustment techniques for linear code time Speed adjustment based on remaining WCET

Dynamic Speed adjustment techniques for linear code time Speed adjustment based on remaining WCET Greedy speed adjustment: Give reclaimed slack to next task rather than all future tasks time

Dynamic Speed adjustment techniques for linear code time WCE time WCET ACET time AV Remaining av. ex. time Speed adjustment based on remaining average execution time WCE S max Remaining time

An alternate point of view time WCE time WCET ACET time AV WCE Reclaimed slack stolen slack

Dynamic Speed adjustment techniques for non-linear code Remaining WCET is based on the longest path Remaining average case execution time is based on the branching probabilities (from trace information). At a p3p3 p2p2 p1p1 minaveragemax

Greedy dynamic speed adjustment  Giving reclaimed slack to the next ready task is not always a correct scheme  Theorem: A reclaimed slack has to be associated with a deadline and can be given safely to a task with an earlier or equal deadline. correct incorrect

aggressive dynamic speed adjustment  Theorem: if tasks 1, …, k are ready and will complete before the next task arrival, then we can swap the time allocation of the k tasks. That is we can add stolen slack to the reclaimed slack  Experimental rule: Do not be very aggressive and reduce the speed of a task below a certain speed (the optimal speed determined by U av )

Outline Introduction to real-time systems Introduction to power management Speed adjustment in frame-based systems Dynamic speed adjustment in multiprocessor environment Tradeoff between energy consumption and reliability Saving power in wireless networks

Multiprocs and AND/OR Applications Real-Time Application  Set of tasks  Single Deadline Directed Acyclic Graph (DAG)  Comp. (c i, a i )  AND (0,0)  OR (0,0): probabilities T1T1 T2T2 T3T3 T4T4 T5T5 (1,2/3) (2,1)(1,1)(4,2)(3,2) T7T7 T6T6 (1,1) 60% 40% The Example TiTi

Slack Stealing Shifting Static Schedule: 2-proc, D = time f T1T1 T4T4 T5T5 T7T7 D L0L0 T1T1 T4T4 T5T5 T7T7 f Shifting D L0L0 T3T3 T2T2 T6T6 L1L1 Recursive if embedded OR nodes T3T3 T2T2 T6T6 T1T1 T7T7 ` L1L1

Proposed Algorithms Greedy algorithm, two phases:  Off-line: longest task first heuristic; Slack stealing via shifting: LST i, EO i  On-line: Same execution order Claim the slack: LST i – t i (t i  LST i ) Compute speed: Meet timing requirement [Zhu-2001]

Proposed Algorithms (cont) Actual Running Trace: left branch, T i use a i Possible Shortcomings  Number of Speed change (overhead)  Too greedy: slow  fast T7T7 f time D T6T6 T1T1 L0L0 T3T3 T2T2 L1L1

Optimal for uniprocessor: Single speed  Energy – Speed: Concave  Minimal Energy when all tasks SAME speed Speculation: statistical information about Application  Static Speculation All tasks f i = max ( f ss, f g i )  Adaptive Speculation Remaining tasks f i = max ( f as, f g i ) Proposed Algorithms (cont)

Outline Introduction to real-time systems Introduction to power management Speed adjustment in frame-based systems Dynamic speed adjustment in multiprocessor environment Tradeoff between energy consumption and reliability Saving power in wireless networks

Basic hypothesis:  Dependable systems must include redundant capacity in either time or space (or both)  Redundancy can also be exploited to reduce power consumption Tradeoff: energy & dependability Time redundancy (checkpointing and rollbacks) Space redundancy

Exploring time redundancy deadline The slack can be used to 1) add checkpoints 2) reserve recovery time 3) reduce processing speed For a given number of checkpoints, we can find the speed that minimizes energy consumption, while guaranteeing recovery and timeliness. S max

More checkpoints = more overhead + less recovery slack D C r Optimal number of checkpoints For a given slack (C/D) and checkpoint overhead (r/C), we can find the number of checkpoints that minimizes energy consumption, and guarantee recovery and timeliness. # of checkpoints Energy

Non-uniform check-pointing Observation: May continue executing at S max after recovery. Advantage: recovery in an early section can use slack created by execution of later sections at S max Disadvantage: increases energy consumption when a fault occurs (a rare event) Requires non-uniform checkpoints.

Non-uniform check-pointing Can find # of checkpoints, their distribution, and the CPU speed such that energy is minimized, recovery is guaranteed and deadlines are met

More checkpoints = more overhead + less recovery slack D C  Optimal number of checkpoints For a given slack (C/D) and checkpoint overhead (  ), we can find the number of checkpoints that minimizes energy consumption, and guarantee recovery and timeliness. # of checkpoints Energy

Triple Modular Redundancy vs. Duplex TMR: vote and exclude the faulty result Duplex: Compare and roll-back if different results Load=0.7  Load=0.5 Load=0.6 Energy efficiency of TMR Vs. Duplex depends on  , and load Duplex is more Energy efficient TMR is more Energy efficient Load=0.7     Load : overhead of checkpoint : ratio of static/dynamic power : slack in the system

Including the hardware cost Assuming the same number of processors and a given task set, to obtain the same reliability, will it be more energy efficient to use TMR or Duplex? Example: 6 processors and 6 identical tasks. Need to look at - the fault model, - the energy model and - the overheads. - the communication cost

Reconfigurable clusters of servers Simplex mode Duplex mode TMR mode Inactive processors Reconfigure your cluster to - achieve required reliability - minimize energy consumption - optimize performance - meet quality of service Example: At a given server’s speed, it is more energy efficient to activate an additional server than to increase the speed of the active servers. At a given server’s speed, it is more energy efficient to power down one of the servers than to reduce the speed of the active servers

Outline Introduction to real-time systems Introduction to power management Speed adjustment in frame-based systems Dynamic speed adjustment in multiprocessor environment Maximizing computational reward for given energy and deadline Tradeoff between energy consumption and reliability Saving power in wireless networks

Saving Power Power is proportional to the square of the distance The closer the nodes, the less power is needed Power-aware Routing (PARO) identifies new nodes “between” other nodes and re-routes packets to save energy Nodes decide to reduce/increase their transmit power

Asymmetry in Transmit Power Instead of C sending directly to A, it can go through B Saves transmit power, but may cause some problems. A B C A B C

Problems due to one-way links. Collision avoidance (RTS/CTS) scheme is impaired  Even across bidirectional links! Unreliable transmissions through one-way link.  May need multi-hop Acks at Data Link Layer. Link outage can be discovered only at downstream nodes. ABC RTS CTS X MSG

Problems for Routing Protocols Route discovery mechanism.  Cannot reply using inverse path of route request.  Need to identify unidirectional links. (AODV) Route Maintenance.  Need explicit neighbor discovery mechanism. Connectivity of the network.  Gets worse (partitions!) if only bidirectional links are used.

SRL: Sub Routing Layer Short reverse routes for one-way links  Improve connectivity substantially.  Also decrease route lengths. SRL discovers and maintains reverse routes for one- way links. It provides a bidirectional abstraction to the routing protocols. Provides services such as reliable transmission and link breakage detection.

Optimization 1: Dynamic SRL The SRL radius of each node could be different. Each node increases radius until it can find reverse routes. Radius decreases if reverse routes are shorter than the radius. Decreases the number of updates that is neighbor-cast: lower overhead.

Optimization 2: On-demand DSRL Routing protocol requests DSRL to find reverse routes for certain one-way links. Reverse routes maintained only for the chosen one-way links. Routing strategy that uses one-way links only when route discovery along bidirectional links fail.

Wireless bandwidth and Power savings In addition to transmit power, what else can we do to save energy? Power has a direct relation with signal to noise ratio (SNR)  The higher the power, the higher the signal, the less noise, the less errors, the more data a node can transmit  Increasing the power allows for higher bandwidth Is it useful to explore the power/bandwidth problem? Is it easy to characterize the problem?

Future work In the future we’ll talk about (or you’ll have a project in!):  Maximizing computational reward for given energy and deadline  Real-time power-aware disks  Rechargeable systems  Combination of network and compute nodes energy savings  Voice interface for saving energy  Operating systems implementations  Compiler/OS combined efforts  You name your favorite project