1 / 27

Power Aware Distributed Systems PAC/C PI Meeting November 1 - 3, 2000

Power Aware Distributed Systems PAC/C PI Meeting November 1 - 3, 2000. USC Information Sciences Institute Brian Schott, Bob Parker Rockwell Science Center Charles Chien UCLA Mani Srivastava University of California, Irvine Rajesh Gupta. Impact

don
Download Presentation

Power Aware Distributed Systems PAC/C PI Meeting November 1 - 3, 2000

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. Power Aware Distributed SystemsPAC/C PI MeetingNovember 1 - 3, 2000 USC Information Sciences InstituteBrian Schott, Bob Parker Rockwell Science CenterCharles Chien UCLAMani Srivastava University of California, IrvineRajesh Gupta

  2. Impact Power-aware algorithms, sensor node RTOS, and middleware will reduce sensor network aggregate energy requirements >1000X. This capability will extend sensor network power dynamic range to span from prolonged (months) quiescent operation to “get me the information now at any cost”. Power instrumentation of existing low-power sensor node provides baseline by which PAC/C tools and technology will be measured. Goals Algorithms. Develop power-aware algorithms for cooperative signal processing that exploit sensor data locality, multi-resolution processing, sensor fusion, and accumulated intelligence. Protocols. Design a distributed sensor network control middleware for power-aware (P-A) task distribution and hardware/software resource utilization migration. Compilers/OS. Create sensor node RTOS to manage key resources – processor, radio, sensors. Systems.Identify hardware power control knobs and readable parameters and make them available to the sensor node power-aware RTOS. Extending dynamic power range for distributed sensor networks. Cooperative Signal Processing Sensor Network Middleware Sensor Node Hardware Control Knobs and Power Aware RTOS Power Aware Distributed Systems Milestones [FY/Q] • P-A RTOS scheduling on research platform [01/Q1]. • Instrumentation board for research platform [01/Q1]. • Compressed image transmission (Laplacian Pyramid) [01/Q1]. • SensorSim simulation tool with P-A extensions [01/Q4]. • Tool for power-aware RTOS kernel synthesis [02/Q4]. • Deployable platform with P-A control “knobs” [02/Q4]. • P-A network resource allocation DP field demo [03/Q2]. • RP w/ sensor-triggered activation & low power sleep [03/Q3]. • High-res multi-look image classification demo [03/Q4].

  3. Instrument a state-of-the-art sensor node to understand and baseline power consumption in current sensor systems. Rockwell WINS is modular: Power Board StrongARM Board Radio Board Sensor Board WINS representative of other sensor nodes in the community. We plan to adapt this node to allow module-level power instrumentation and logging both in the lab and in the field. Sensor Network Baseline

  4. Insert a power isolation board between each module. Signals are passed through, power supplies are isolated. Microcontroller provides power monitoring and power control from a host’s serial port (workstation, laptop or iPAQ). Event “snooping” may be possible to trigger data acquisition in the field. StrongARM Radio Sensor PADS Power Isolator PADS Power Isolator PADS Power Isolator Power Instrumentation Battery Pack

  5. Application Scenario • SensIT Application Scenario: vehicle detection / tracking using acoustic, seismic, and I/R sensors. • SensIT metrics include latency, accuracy, false alarm rate, etc. • PAC/C adds sensor net lifetime, coverage area, and energy.

  6. SensIT SITEX00 experiment completed in August 2000 at Twenty-nine Palms, CA. RSC/UCLA/ISI/VT experimented with sensor net GUIs and sensor network coverage algorithms. The next opportunity is SensIT experiment in March, 2001. PADS plans to power-instrument some WINS nodes as a secondary experiment at this exercise. Use our power data and BBN ground truth to define baseline. PADS will use SensIT and other Rockwell exercises to field power-instrumented baseline and test best-of-breed PAC/C techniques and technology. SensIT Experiments http://www.dsic-web.net/ito/meetings/sensit2000oct/presentations/SITEX2000Review.pdf

  7. Identify hardware knobs that can be provided by modules (radio and processor systems) that can be altered dynamically, Identify externally readable parameters (power, BER, signal strength, battery, etc.) that can be provided to a power-aware runtime system. Simplify integration of advanced PAC/C technology into an open sensor network platform and evaluate this technology against measured baseline. Examine system-level aspects of existing sensor nodes. Note that most nodes are CPU-centric in that the radio, GPS, and sensors are wired up to serial ports or system bus, of an embedded processor. The dilemma is that the CPU must wake up on any event in the sensor node. Is there another approach which allows most of the sensor node to be turned off most of the time? PADS Research Platform

  8. Distributed Sensor Node Approach • Make each module an independent actor on a multi-master serial bus such as I2C (400Kb, 4Mb*). • 87C554 Microcontroller - 16 mA Active, 4 mA Idle, 50 uA Shutdown. • Create common command set for peer to peer communication and control of modules. • Localize specific processing as close to modules as possible (perform energy threshold on seismic board, etc.). • A StrongARM may be used for application control and data processing, but could distribute “event handlers” to local microcontrollers and power down most of the time. I2C + Power

  9. Distributed node architecture makes it much easier to integrate PAC/C modules that don’t fit. Most existing sensor modules and systems have an serial port. Form factor not an issue for initial laboratory experiments. Enables simple module emulation and module testing from a workstation or laptop. Power control and power monitoring can be incorporated into bridge board. Basically the same design as the WINS power isolator boards! Research Platform Technology Integration / Emulation I2C Serial Port Bridge Serial Port Bridge Serial Port Bridge Experimental V-scaling StrongARM Board Emulated Sensor WINS Node

  10. Power Analysis of RockwellWINS Nodes (Measurements) Summary • Processor = 360 mW • doing repeated transmit/receive • Sensor = 23 mW • Processor : Tx = 1 : 2 • Processor : Rx = 1 : 1 • Total Tx : Rx = 4 : 3 at maximum range

  11. CommunicationSubsystem Rest of the Node GPS RadioModem MicroController CPU Sensor Power-aware Multihop Packet Forwarding Architecture • Problem: radio often simply relays packets in multihop network • Traditional approach: main CPU woken up, packets sent to it across serial bus • power hungry computing and communication operations • Our approach: exploit programmable micro-controller in the Communication Subsystem to handle common cases of packet routing • can also do operations such as combining of packets with redundant information • Key challenge: how to do it so that every new routing protocol will not require a new radio firmware • Solution: application-defined all-layer packet routing …zZZ MultihopPacket MultihopPacket CommunicationSubsystem Rest of the Node GPS RadioModem MicroController CPU Sensor Our Approach Traditional Approach

  12. Application-defined All-layer Packet Routing CommunicationSubsystem Packet Classifier GPS Application-DefinedMatching Rules& Actions RadioModem MicroController • Packet-classifier and packet-modifier driven by application defined matching rules and actions • Matching rules: and/or expressions using =, <, >, range operators on arbitrary packet fields (offset, length) • Actions: accept, forward, drop, field increment/decrement etc. • Rules and actions operate on arbitrary packet fields (any layer) • fields specified as (offset, length) • only simple, common cases handled at the radio • for complex cases packet sent to the main processor • Expressiveness: implemented the following as test cases • Node ID-based addressing and routing (IP-like) • Point-cast (send to a circular area specified as destination) • Current proof-of-concept prototype being done on Rockwell node Packet Modifier

  13. Power-aware RTOS Scheduling Under Deadline Constraints • Consider task set (period, WCET, deadline) • {(10, 3, 10), (14, 7, 14)} • CPU utilization = 3/10 + 7/14 = 80% • Obvious power management strategies: • Shutdown when idle • saves 20% power • Can we slow CPU by 20% (& reduce V) for more savings? • NO, as deadlines will no longer be met • However, can slow by x 14/13 and lower voltage to still meet deadlines, and shutdown during idle time • saves 22.5% in power • Problem: current approaches use WCET (worst case execution time), and aim at not missing any deadline

  14. Reality #1: Significant Variation in Execution Times • WCET : BCET is typically >> 1, e.g.: • But, execution time variations in sensor data are not random • temporal correlation in underlying physical signal • can attempt to predict!

  15. Reality #2: Sensor Applications Tolerant to Deadline Misses • Computation deadline misses lead to data loss • Packet loss common in wireless links • e.g. a wireless link of 1E-4 BER means packet loss rate of 4% for small 50 byte packets • radio links in sensor networks often worse • Significant probability of error in sensor signals • noisy sensor channels • Applications designed to tolerate noisy/bad data by exploiting spatio-temporal redundancy • high transient losses acceptable if localized in time or space If the communication is noisy, and applicationsare loss tolerant, is it worthwhile to strivefor perfect noise-free computing?

  16. Exploiting Execution-time Variation and Tolerance to Deadlines • Our strategy: predict execution time of task instance and dynamically scale voltage even more aggressively so as to minimize shutdown • Execution time prediction • learn distribution of execution times (pdf) • Tasks with distinct modes can help the OS by providing hint after starting • E.g. MPEG decode can tell the OS after learning whether the frame is P, I, or F • But, some deadlines are missed! • Adaptive control loop to keep deadlines missed under control • Typical result: 1.5-3x higher power saving compared to best conventional schemes with dynamic voltage, with < 1% deadlines missed • Provides adaptive power-fidelity trade-off

  17. Power-aware RTOS Scheduler Implementation • RTOS predicts the remaining runtime (at max CPU speed) of a task instance • calculated whenever the task instance enters the system, or is preempted • based on run-times of previous instances of the task, and the run-time consumed so far • e.g. weighted mean • e.g. a coarse-grained discrete probability distribution of actual run time of each task is calculated, and used to calculate E[remaining_runtime | runtime_so_far] • adaptively adjusts a multiplicative factor dependent on recent deadline misses • Voltage scheduling strategy • if only one task remains in the system, and its deadline is earlier than the arrival of a new task, the CPU is slowed down such that the expected end time (based on predicted remaining run time) of the task equals its allowed deadline • otherwise the CPU runs at maximum speed

  18. Current Status • Simulation tool for RTOS power management evaluation • PARSEC discrete event simulation language • Two communicating entities: • Task Generator • generates task instances with run times according to a trace or a distribution • RTOS • sets CPU speed by setting voltage and frequency • implements runtime predictor • Variety of task sets from literature • Note: non-predictive scheme is obtained by setting predictor to always return WCET – run time so far. • Implementation in progress in eCoS RTOS

  19. Sample Simulation Results #1(17 Task Set; EDF Scheduling)

  20. Sample Simulation Results #2(17 Task Set; RM Scheduling)

  21. Deployable Platform Sensor 1 Sensor 2 Embedded Radio Logic & Control • Leverage existing Rockwell Wireless Integrated Networked Sensor (WINS) technology based on the StrongARM. • Develop and implement controls and monitors to enable power management by the middleware and RTOS. • E.g. cache sleep/on modes, processor sleep/idle/on, and peripheral idle/on modes. • Provide API abstraction to facilitate power management. • Advanced power-aware features will be implemented guided by experimental results obtained from the research platform. • Upgrade to higher-speed, lower power next-generation StrongARM when it becomes available. Signal Conditioning Signal Processing Sensor 3 Sensor n Memory Power Current WINS Node 2.5” X 2.5” X 4” WINS Node in 2000 1”x1”x1”

  22. JIT Power-aware Communications • AWGN • Approximately 10 dB SNR requirement for 0.001% BER. • Raleigh fading • Approximate 45 dB SNR requirement for 0.001% BER. • Assume 5 dB NF, R4 path loss, 900 MHz carrier frequency, 100 kbps bitrate, and 10 dB link margin. • Transmit power is 12.5 dBm for AWGN case at 100 m. • Transmit power is 47.5 dBm for Rayleigh fading with no coding. • With coding the transmit power is increased to 22.5 dBm. • But the computation overhead is 100X for a K=9 rate ½ convolutional code.

  23. Reconfigurable Power-awareCommunications Techniques • Traditional approaches • Point solution, usually designed for the worst-case channel condition • Manage power at the link layer only, e.g. power control. • Proposed approach • Provides adaptation of the physical layer and supports adaptation at higher protocol layers (e.g. routing). • Utilizes reconfigurable technology (e.g. FPGA). • Adapts not only digital processing but also analog processing. • Runtime reconfigurable library (100X power dynamic range) • Direct-sequence spread-spectrum modem (adaptable processing gain) • FEC coder/encoder: block codes and convolutional codes. • Un-equalized QAM, including BPSK and QPSK. • Reconfigurable analog processing (10-20X power dynamic range) • Adapt the input bandwidth, spanning a range of 10 kHz to 1000 kHz. • Configures mode of power amplifier (Class A and E/F).

  24. Some Potential Operation Scenarios • Typical operation • Good channel => • Uncoded transmission • Noisy channel => • Simple to complex FEC coding and/or interleaving. • Decrease BW • Interference channel => • Increase processing gain. • Mission critical operation • Un-equalized QAM, high BW, and Class A operation. • Add FEC and processing gain as needed. • Sentry • GMSK with Class E operation. • Low BW. • Add FEC and processing gain as needed.

  25. Reconfigurable Radio Architecture

  26. Field Demonstrations

  27. Technology Transfer & Commercialization Collins PLGR LAN provides situation awareness to individual soldiers. RSC’s Highly Deployable Remote Access (HiDRA) (hidra.rsc.rockwell.com) Existing as well as future Rockwell products can greatly benefit from the power-aware technology developed under this program.

More Related