html5-img
1 / 28

System-Level Power-Aware Design Techniques in Real-Time Systems

System-Level Power-Aware Design Techniques in Real-Time Systems. Osman S. Unsal, Israel Koren, System-Level Power-Aware Design Techniques in Real-Time Systems, Proceedings of IEEE, Vol. 91, No. 7, July 2003. Power Management. Why & What: Power Management?

idana
Download Presentation

System-Level Power-Aware Design Techniques in Real-Time Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. System-Level Power-Aware Design Techniques in Real-Time Systems Osman S. Unsal, Israel Koren, System-Level Power-Aware Design Techniques in Real-Time Systems, Proceedings of IEEE, Vol. 91, No. 7, July 2003.

  2. Power Management • Why & What: Power Management? • Rapid growth of worldwide total power dissipation • 87M CPUs consumed 160MW in 1992 -> 500M CPUs consumed 9,000 MW in 2001 • Battery operated: Laptops, PDAs, Cell phones, Wireless Sensors, ... • Heat: Complex Servers (server farms, multiprocessors, etc.) • Power Aware: MaintainQoS while reducing energy Source: Daniel Mosse (CS1651 at Univ. of Pittsburg)

  3. Why System-Level Design? • Power management at various system layers • Circuit & device level, archiecture & compiler, OS & network design • Most existing research regarding power-aware RT systems focus on power-aware RT scheduling • CPU is only a single source of power consumption!

  4. Misconceptions about power-aware design • Power-aware ≠ low-power (minimize power consumption) • Delay some instruction execution, e.g., to reduce peak power -> Executes longer & consumes more power • Decreasing average power does not imply decreasing max power • Power ≠ energy efficiency • Energy = ∫power • Perf may degrade resulting in more energy consumption

  5. Misconceptions about power-aware design • Power-constrained ≠ energy-constrained • solar power (infinite source) vs. battery power • Energy-constrained systems do not always target energy minimization • Charge = f(battery capacity, rate of discharge) • Goal is battery lifetime extension

  6. Motivations for power-aware design for RT sytems • Limited energy-budget & timing constraints, e.g., in space & multimedia applications • Limited form factor & low heat dissipation, e.g., in avionics, robotics & space missions • Often overdesigned to support timing guarantees under the wosrt case • Tasks do not run until their WCET -> Energy inefficient • Fault-tolerance • Reliability via replication -> high power consumption

  7. What is system-level power-aware design? • Power-awareness embedded in every step of system design • Power-compiler can do instruction scheduling to reduce power consumption • OS-level heuristic may scale down f and Vdd • Network-level schems may put the network I/F into standby mode • Today, we will focus on OS & network levels

  8. OS Level • Voltage & frequency scaling • I/O devices • Power and energy analysis of RTOS • Distributed RT systems • Soft real-time systems

  9. Power Management • How? • Power off un-used parts: LCD, disk for Laptop • Gracefully reduce the performance • CPU: dynamic power Pd = Cef * Vdd2 * f[Chandrakasan-1992, Burd-1995] • Cef : switch capacitance • Vdd : supply voltage • f : processor frequency  linear related to Vdd Source: Daniel Mosse (CS1651 at Univ. of Pittsburg)

  10. Energy f 0.6E T1 T2 T2 T1 time 0.6E T1 T2 time fmax/2 E/4 T1 T2 time Power Aware Scheduling • Static Power Management (SPM) • Static slack: uniformly slow down all tasks [Weiser-1994, Yao-1995, Gruian-2000] fmax Static Slack D E T1 T2 idle time Source: Daniel Mosse (CS1651 at Univ. of Pittsburg)

  11. Dynamic Slack fmax/2 T1 time fmax/3 0.12E T1 T2 time Power Aware Scheduling • Dynamic Power Management (DPM) • Dynamic slack: non-worst execution 10% [Ernst-1997] • DPM: [Krishna-2000, Kumar-2000, Pillai-2001, Shin-2001] fmax Static Slack D E T1 T2 idle time E/4 fmax/2 T1 T2 time • Multi-Processor • SPM: length of schedule over deadline • DPM ??? Source: Daniel Mosse (CS1651 at Univ. of Pittsburg)

  12. References (Power-Aware RT Scheduling) • [Chandrakasan-1992] A. P. Chandrakasan and S. Sheng and R. W. Brodersen. Low-Power CMOS Digital Design. IEEE Journal of Solidstate Circuit, V27, N4, April 1992, pp 473--484 • [Burd-1995] T. D. Burd and R. W. Brodersen. Energy efficient cmos microprocessor design. In Proc. of The HICSS Conference, pages 288-297, Maui, Hawaii, Jan. 1995. • [Weiser-1994] M. Weiser, B. Welch, A. J. Demers, and S. Shenker. Scheduling for reduced CPU energy. In Operating Systems Design and Implementation, pages 13-23, 1994 • [Yao-1995] F. Yao, A. Demers, and S. Shenker. A scheduling model for reduced cpu energy. In Proc. of The 36th Annual Symposium on Foundations of Computer Science, pages 374-382, Milwaukee, WI, Oct. 1995. • [Gruian-2000] F. Gruian. System-Level Design Methods for Low-Energy Architectures Containing Variable Voltage Processors. The Power-Aware Computing Systems 2000 Workshop at ASPLOS 2000, Cambridge, MA, November 2000 • [Ernst-1997] R. Ernst and W. Ye. Embedded program timing analysis based on path clustering and architecture classification. In Proc. of The International Conference on Computer-Aided Design, pages 598–604, San Jose, CA, Nov. 1997. • [Krishna-2000] C. M. Krishna and Y. H. Lee. Voltage clock scaling adaptive scheduling techniques for low power in hard real-time systems. In Proc. of The 6th IEEE Real-Time Technology and Applications Symposium (RTAS00), Washington D.C., May. 2000. • [Kumar-2000] P. Kumar and M. Srivastava, Predictive Strategies for Low-Power RTOS Scheduling, Proceedings of the 2000 IEEE International Conference on Computer Design: VLSI in Computers and Processors • [Pillai-2001] P. Pillai and K. G. Shin. Real-Time Dynamic Voltage Scaling for Low-Power Embedded Operating Systems, 18th ACM Symposium on Operating Systems Principles (SOSP?1), Banff, Canada, Oct. 2001 • [Shin-2001] D. Shin, J. Kim and S. Lee, Intra-Task Voltage Scheduling for Low-Energy Hard Real-Time Applications, IEEE Design and Test of Computers, March 2001 • [Zhu-2001] D. Zhu, R. Melhem, and B. Childers. Scheduling with Dynamic Voltage/Speed Adjustment Using Slack Reclamation in Multi-Processor RealTime Systems, RTSS'01 (Real-Time Systems Symposium), London, England, Dec 2001 152 Source: Daniel Mosse (CS1651 at Univ. of Pittsburg)

  13. I/O devices • Much less work has been done compared to VS (voltage scaling) in real-time systems • Swaminathan et al [72] • Power-aware I/O device scheduling for hard real-time systems • Tasks are independent but not periodic • A priori knowledge of task schedule & device usage list required

  14. Power & energy analysis of RTOS • Power consumption of μc-OS on Fujitsu SPARClite processor • μc-OS: Open-source embedded RT kernel introduced in an earlier lecture for project ideas • Evaluate power consumption by system calls [73] • μc-OS, Ecnidna, NOS (baseline “bare-bones” scheduler) [74] • RTOS overheads are two to four times higher than NOS • Poorly design idele loops can double the energy consumption

  15. Power & energy analysis of RTOS • Acquaviva [75] • Increasing context switch frequency from 0Hz to 10Khz does not affect energy consumption -> Context switch mechanism in RTOS is energy efficient • More energy is consumed when cache flushing effect during context-switch is considered • I/O: CPU sends data bursts > output buffer -> Considerable energy consumption when buffer is full or when it polls a synchronization variable (similar to [74])

  16. Distributed/Multiprocessor real-time systems • Reminder • Tightly coupled multiprocessor system • Multiple processors are connected at the bus level and share main memory • Extreme: multicore with multiple processors on a chip • Loosely coupled multiprocessor system (e.g., cluster) • Multiple, stand-alone processors connected via, e.g., Gigabit Ethernet

  17. Distributed/Multiprocessor real-time systems • Classic RT scheduling ≠ Power-aware one • Example: a tightly coupled RT system with 2 processors, 2 memory banks, 1 ready queue • Apply EDF • Assign a task to the first available processor • Put memory bank(s) into sleep mode if not used

  18. Distributed/Multiprocessor real-time systems • Task set • Assume memory utilization is linearly dependent on exec time

  19. Distributed/Multiprocessor real-time systems • Classic Load Balancing (LB) • Try to balance memory bank utilization • Assign T1 & T2 to bank 1 (bank utilization 70%) & T3 & T4 to bank 2 (BU 54.1%) • Power-Aware (PA) • Assign harmonically related tasks to the same bank • Tasks are simultaneously active more often • Assign T1 & T3 (BU 36.6%) to bank 1 & T2 & T4 to bank 2 (BU 87.5%)

  20. Distributed/Multiprocessor real-time systems • PA vs. LB Several variations possible: Another project idea!

  21. Soft real-time systems [77] • Hand-held, pocket computes – audio, video, GPS, ... • Power profile of a pocket computer shows more dynamic power profile than a laptop • Using a single JVM is 25% more energy efficient than using one JVM per application • Just-in-time compilation is power efficient

  22. Soft real-time systems: Battery lifetime • Energy-aware QoS tradeoff [79] • Energy-aware scheduling favoring low energy & critical tasks • Tunable toward extended battery life at the cost of perf • Battery life can be extended up to 100% with perf degradation of 40% • Open & closed-loop approaches [80] • Tight cooperation btwn OS and applications for energy savings [81]

  23. Soft real-time systems: Web server • Web workloads are bursty • 1998 Nagano Winter Olympic • 1840 hits/sec during peak time • Only 459 hits/sec in average • Voltage scheduling & frequency scheduling during the predicted low activity time -> 23% - 36% energy savings • Heat is also a critical factor in this kind of systems

  24. Network Level • Much less work has been done compared to RT scheduling & RTOS • QoS support for audio & video streaming, e.g., RSVP (Resource Reseravation Protocol), RTP, RTSP, is a different story • ATM: Constant Bit Ratio & Variable Bit Ratio • Research issues • Limited hard RT support, e.g., CAN (Control Area Network) • Overlay networks? • Wireless networks?

  25. Network Level • Wireless communications: Relatively new technologies • WiFi (IEEE 802.11) • Energy-efficient MAC (Medium Access Control) • Example: S-MAC for Wireless Sensor Networks • In WSNs, duty cycle ≤ 1%; 802.11 too expensive • Efficient sleep scheduling: If a node loses contention for the medium, it goes to sleep for the duration specified in each packet • RTS/CTS for an entire message that can be multiple packets • Fairness in WSNs is not as important as other wireless ad hoc networks • S-MAC consumes 2-6 times less energy than 802.11 [96]

  26. Above the MAC layer • LEACH (Low-Energy Adaptive Clustering Hierarchy) • Cluster head/cluster can aggregate data • Randomly elect a cluster head • RAP & SPEED • Real-time protocols in WSNs • To be discussed later in this class

  27. Shortest path vs. max power reduction Balance timing & power constraints!

  28. Questions?

More Related