Transcript pacc_pads_pi_nov00 - Power Aware Distributed Systems

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
Power Aware Distributed Systems
Extending dynamic power range
for distributed sensor networks.

Cooperative
Signal Processing

Sensor Network
Middleware

Sensor Node
Hardware Control
Knobs and Power
Aware RTOS

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.
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].
Sensor Network Baseline

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.
Power Instrumentation
Battery Pack

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
PADS Power Isolator
Radio
PADS Power Isolator
Sensor
PADS Power Isolator
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.
SensIT Experiments
http://www.dsic-web.net/ito/meetings/sensit2000oct/presentations/SITEX2000Review.pdf


SensIT SITEX00 experiment
completed in August 2000 at
Twenty-nine Palms, CA.

The next opportunity is SensIT
experiment in March, 2001.

RSC/UCLA/ISI/VT experimented
with sensor net GUIs and sensor
network coverage algorithms.


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 powerinstrumented baseline and test
best-of-breed PAC/C techniques
and technology.
PADS Research Platform



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 CPUcentric 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?
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
Research Platform Technology
Integration / Emulation
I2C

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.

Serial
Port
Bridge
Serial
Port
Bridge
Serial
Port
Bridge
Experimental
V-scaling
StrongARM
Board
Emulated
Sensor
Basically the same design as the
WINS power isolator boards!
WINS Node
Power Analysis of Rockwell
WINS Nodes (Measurements)
Processor
Active
Active
Active
Active
Active
Active
Seismic Sensor
On
On
On
On
Removed
On
Radio
Rx
Idle
Sleep
Removed
Removed
Tx (36.3 mW)
Tx (27.5 mW)
Tx (19.1 mW)
Tx (13.8 mW)
Tx (10.0 mW)
Tx (3.47 mW)
Tx (2.51 mW)
Tx (1.78 mW)
Tx (1.32 mW)
Tx (0.955 mW)
Tx (0.437 mW)
Tx (0.302 mW)
Tx (0.229 mW)
Tx (0.158 mW)
Tx (0.117 mW)
Power (mW)
751.6
727.5
416.3
383.3
360.0
1080.5
1033.3
986.0
942.6
910.9
815.5
807.5
799.5
791.5
787.5
775.5
773.9
772.7
771.5
771.1
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
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
…zZZ
Multihop
Packet
GPS
Radio
Modem
Communication
Subsystem
Micro
Controller
Rest of the Node
CPU
Sensor
Multihop
Packet
GPS
Radio
Modem
Traditional Approach
Communication
Subsystem
Micro
Controller
Rest of the Node
CPU
Sensor
Our Approach

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
Application-defined All-layer Packet
Routing
GPS
Radio
Modem



Packet Modifier
Matching rules: and/or expressions using =, <, >, range operators on arbitrary packet
fields (offset, length)
Actions: accept, forward, drop, field increment/decrement etc.
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



Micro
Controller
Application-Defined
Matching Rules
& Actions
Rules and actions operate on arbitrary packet fields (any layer)


Packet Classifier
Packet-classifier and packet-modifier driven by application defined matching
rules and actions


Communication
Subsystem
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
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

saves 20% power
 Can

when idle
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
Reality #1: Significant Variation in
Execution Times

WCET : BCET is typically >> 1, e.g.:
Program
Description
Circle
Circle drawing
DES
Data Encryption
DJPEG
JPEG decompression 128x96 color
FDCT
JPEG forward DCT
FFT
BCET
WCET
WCET/BCET
431
15,958
37
73,912
672,298
9.1
12,703,432
122,838,368
9.7
5,587
16,693
3
1024-point FFT
1,589,026
3,974,624
2.5
Matcnt
Summation of 2 100x100 matrices
1,722,105
8,172,149
4.7
Piksrt
Insertion sort of 10 elements
236
5,862
24.8
Sort
Bubble sort of 500 elements
13,965
50,244,928
3598
Stats
Sum, mean, var of 2 1000-size arrays
1,007,815
2,951,746
2.9
But, execution time variations in sensor data are not
random


temporal correlation in underlying physical signal

can attempt to predict!
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 applications
are loss tolerant, is it worthwhile to strive
for perfect noise-free computing?
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
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

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
Sample Simulation Results #1
(17 Task Set; EDF Scheduling)
% Power
Reduction
60
40
20
0
10
30
50
70
90
BCET/WCET
Lo w P o wer Scheme witho ut P redictio n and A daptio n
Strategies
Lo w P o wer Scheme with P redictio n and witho ut
A daptio n Strategy
Lo w P o wer Scheme with P redictio n and A daptio n
Strategies
Deadlines Missed in Avionics Task
Set Using EDF Scheduling
0.6
% Deadlines
Missed
Pow er Reduction in Avionics Task
Set Using EDF Scheduling
0.4
0.2
0
10
30
50
70
90
BCET/WCET
Low Power Scheme with Prediction and without
Adaption Strategy
Low Power Scheme with Prediction and Adaption
Strategies
Pow er Reduction in Avionics Task
Set Using RM Scheduling
Deadlines Missed in Avionics Task
Set using RM Scheduling
60
40
20
0
10 20 30 40 50 60 70 80 90 100
BCET/WCET
Lo w P o wer Scheme witho ut P redictio n and A daptio n
Strategies
Lo w P o wer Scheme with P redictio n and witho ut
A daptio n Strategy
Lo w P o wer Scheme with P redictio n and A daptio n
Strategies
% Deadlines
missed
% Power Reduction
Sample Simulation Results #2
(17 Task Set; RM Scheduling)
0.6
0.4
0.2
0
10
30
50
70
90
BCET/WCET
Low Power Scheme with Prediction and without
Adaption Strategy
Low Power Scheme with Prediction and Adaption
Strategies
Deployable Platform
Current WINS Node
2.5” X 2.5” X 4”
Power
Embedded
Radio
Sensor n
Logic &
Control
Sensor 3
Signal
Processing
Sensor 2
Signal
Conditioning
Sensor 1
Memory
WINS Node in 2000
1”x1”x1”

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.
JIT Power-aware Communications
10
10
Bit Error Rate
10
10
10
10
10
10
10
0

-1
AWGN
 Approximately
10 dB SNR
requirement for 0.001%
BER.
-2
-3
Rayleigh Fading
-4

AWGN
-5
Raleigh fading
 Approximate
45 dB SNR
requirement for 0.001%
BER.
-6
-7
-8
0
5
10
15
20
25
30
35
40
45
50
Eb/N0 (dB)

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.
Reconfigurable Power-aware
Communications 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).
Some Potential Operation Scenarios

Typical operation
 Good

Uncoded transmission
 Noisy


channel =>
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.
Reconfigurable Radio Architecture
Battery Lifetime Monitor
Application
Middleware
API
Interface
Communication
Reconfigurable
Modules
Storage
Interface
RTOS
Channel Monitor
Modem
Analog
Interface
RF
Reconfiguration Control
Field Demonstrations
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.