Power Managerlu/cse467s/slides/power3_wsn1.pdf · 2012. 2. 2. · Chenyang Lu CSE 467S 5 ACPI...

Chenyang Lu CSE 467S 1

Power Manager


HW vs. SW?• Software (OS-based) power manager

dominates due to flexibility• Hardware and software co-design

• Software implements policy• Hardware implements power change mechanisms

• Need standard interfaces to deal with hardware diversity• Different vendors• Different devices: processor, sensor, controller …


Advanced Configuration and Power Interface (ACPI)Open standard for power management services.

Hardware platformdevices, processor, chipset

devicedrivers

ACPI BIOS

OS kernel

applicationspower

management


System States


ACPI Global Power States• Used as contracts between hw and OS vendors• G3: mechanical off – no power consumption• G2: soft off – restore requires full OS reboot• G1: sleeping state

• S1: low wake-up latency with no loss of context• S2: low latency with loss of CPU/cache state• S3: low latency with loss of all state except memory• S4: lowest-power state with all devices off

• G0: working state


Device Power States• Device power state is invisible to the

user• Some device may be inactive when the

system is in working state• Each device may be controlled by a

separate PM policy


Reduce power in working state


Holistic View of Power Consumption• Instruction execution (CPU)• Cache (instruction, data)• Main memory• Other: non-volatile memory, display,

network interface, I/O devices


Sources of energy consumption• Relative energy per operation (Catthoor

et al):• memory transfer: 33• external I/O: 10• SRAM write: 9• SRAM read: 4.4• multiply: 3.6• add: 1


Optimize Memory System• Different instructions Different energy

consumption• Energy drain: register << cache (SRAM) <<

memory (DRAM)→Most energy reduction comes from

optimizing memory system


Cache behavior is important• Energy consumption has a sweet spot as

cache size changes:• cache too small: burning energy on external

memory accesses;• cache too large: cache itself burns too much

power.


Impacts of Cache Size


Optimizations• Reduce memory footprint

• Reduce code size• Analyze footprint to find right size

• Stack, heap…• Find correct cache size

• Analyze cache behavior (size of working set)• Minimize memory and cache access

• Use registers efficiently less cache access• Identify and eliminate cache conflicts less

memory access• Better performance More idle time!


Wireless Sensor NetworksA Quick Overview• sensors + microprocessor + wireless

Berkeley Smart Dust


Hardware Technology


The Hardware Challenge• Miniature hardware devices must be

manufactured economically in large numbers• Microprocessors• MEMS sensors/actuators• Wireless communication

5’’X3’’ 1’’X1’’ 1 mm2 1 nm2


MICA Motes• Radio Communication: 40 Kbps max• Commercial-off-the-shelf components

1’’X1’’


Smart Dust• Current: 5 mm; in ten years: 1 mm float in

the air!• Radio?

• Nowhere to put antenna!• Require complex circuits energy-inefficient


Passive Optical CommunicationTop View of the Interrogator

CCD Camera Lens

Frequency-Doubled Beam45o mirror

Polarizing Beamsplitter

Quarter-wavePlateFilter

0.25% reflectance on each surface

YAG Green Laser Expander

K. Pister et. al., http://robotics.eecs.berkeley.edu/~pister/SmartDust/presentations/MEMSPIJan00.ppt


Optical Communication• Pros

• Space multiplexing• Passive optical communication: energy-free

on dusts!• Cons

• Require line of sight• Much more challenging for active multi-hop

communication• aiming control


Amorphous Computing• Computers produced by bio engineering

• Cells as logic gates• Basic inverter: Concentration of protein Z

is inversely proportional to concentration of protein A.

• NAND gate: Production of protein Z is inhibited by presence of proteins A and B.


Nano-scale Computing• DNA manipulation can organize cells into

engineered patterns • The foundation for construction of

complex sub-nano-scale extra-cellular circuits:• Biological system – machine shop• Proteins – machine tools• DNA – control tapes

• Circuits are fabricated in large numbers by cheap biological processes

• Truly ubiquitous! Smart paint, fabric …


Great Duck Island Habitat Monitoring• Usage patterns of burrows• Burrow and environmental

changes• Differences between

nesting areas and others



Great Duck Island Requirements• Longevity: 9-month season

• Super-low Power budget• Need extreme power management!

• Non-intrusive• Management from remote

• System health monitoring • Retasking/reconfiguration through wireless

• Maté, Agilla (from MobiLab)• Timing requirements (non-real-time)

• 5-10 min: entry/leave• 2-4 hr: environmental differential


Great Duck Island Tiered Architecture

http://www.greatduckisland.net


Mote and TinyOS


Hardware Constraints

• Severe constraints in power, size, and costtranslated to:• Slow CPU• Short-distance, low-bandwidth radio• Small memory• Limited hardware parallelisms

• CPU hit by many interrupts!• Support sleep mode in hw components


Mote• CPU: 4 MHz, 8 bit, ATMEL

• NO kernel/user protection• Raw peripherals a lot work for CPU:

• Collect data from sensors• Process every bit to/from radio• Arbitrate bus

• Radio: 900 Hz• Rene: 19.2 kbps• Mica: 40 kbps (max), up to 1,000 feet (power adjustable)• No byte level processing

• Memory: Harvard Architecture• Rene: 512 B data; 8K code• Mica: 4 KB data; 128 KB code

• Two AA battery• 3 days of continuous active operation

• Sleep modes: idle/power-down/power-save


Software Challenges• Small memory footprint• Efficient in power and computation• Lack hardware parallelism OS provides

concurrency-intensive operation• Real-time• Diversity in applications and design

• Efficient modularity• Reconfigurable hardware• Software & hardware codesign


How about a traditional embedded OS?• Big!• Multi-threaded architecture

• Large number of threads large memory• Context switch overhead

• I/O model• Blocking I/O (stop and go): waste memory on blocked threads• Polling (busy-wait): waste CPU cycles and power

• Protection between applications and kernel• Overhead for crossing kernel/user boundary & interrupt

handling• Pros

• Clean & simple programming model• Priority-based scheduling support• Robust (protect kernel)


Real time operating systems

• QNX context switch = 2400 cycles on x86• pOSEK context switch > 40 µs• Creem -> no preemption

Name Code Size Target CPUpOSEK 2K MicrocontrollerspSOSystem PII->ARM ThumbVxWorks 286K Pentium -> Strong ARMQNX Nutrino >100K Pentium II -> NECQNX RealTime 100K Pentium II -> SH4OS-9 Pentium -> SH4Chorus OS 10K Pentium -> Strong ARMARIEL 19K SH2, ARM ThumbCreem 560 bytes ATMEL 8051


TinyOS Solutions• Support concurrency: event-driven architecture• Modularity: application = scheduler + graph of components

• Compiled into one executable • Efficiency: Get done quickly and sleep

• Event = function calls• Less context switch: FIFO/non-preemptable scheduling• No kernel/application boundary

CommunicationActuating Sensing Communication

Application (User Components)

Main (includes Scheduler)

Hardware AbstractionsModified from D. Culler et. Al., TinyOS boot camp presentation, Feb 2001


TinyOS component model• Component has:

• Frame (memory)• Tasks: thread (computation)• Interface:

• Command • Event

• Frame: static storage model – compile-time allocation

• Command and events = function calls• Clean (hw-like) interface

• No shared memory or global variables• Replace hw with sw and vice versa

Messaging Component

Internal StateInternal Tasks

Commands Events


A Complete Application

RFM

Radio byte (MAC)

Radio Packet

i2c

Tempphoto

Messaging Layer

clocksbit

byte

packet

Routing Layer

sensing applicationapplication

HW

SW

ADC

messaging

routing

D. Culler et. Al., TinyOS boot camp presentation, Feb 2001


TOS Component//AM.comp//

TOS_MODULE AM;

ACCEPTS{

char AM_SEND_MSG(char addr, char type, char* data);

void AM_POWER(char mode);

char AM_INIT();

};

SIGNALS{

char AM_MSG_REC(char type,char* data);

char AM_MSG_SEND_DONE(char success);

};

HANDLES{

char AM_TX_PACKET_DONE(char success);

char AM_RX_PACKET_DONE(char* packet);

};

USES{

char AM_SUB_TX_PACKET(char* data);

void AM_SUB_POWER(char mode);

char AM_SUB_INIT();

};

Messaging Component

AM_SUB_INIT

AM_SUB_POWER

AM_SUB_TX_PACKET

AM_TX_PACKET

_DONE

AM_RX_PACKET

_DONE

Internal State

AM_INIT

AM_POWER

AM_SEND_MSG

AM_MSG_REC

AM_MSG_SEND_DONE

Internal Tasks

Commands Events


TinyOS Two-level Scheduling• Tasks do intensive computations

• Unpreemptable FIFO scheduling• Bounded number of pending tasks

• Events handle interrupts• Interrupts trigger lowest level events• Events can signal events, call commands, or post tasks

• Two priorities• Event/command• Tasks

Hardware

Interrupts

even

ts

commands

FIFOTasks

POSTPreempt

Time

commands


How to handle multiple data flows?

• Data/interrupt are handled by interrupt/event• Respond to it quickly: A sequence of non-blocking

event/command (function calls) through the component graph

• e.g., get bit out of radio hw before it gets lost• Post tasks for long computations

• e.g., encoding• Assumption: long computation are not emergent

• Preempting tasks to handle new data


Receiving a message

Timing diagram of event propagation


How should network msg be handled?

• Socket/TCP/IP?• Too much memory for buffering and threads

• Data are buffered in network stack until application threads read it• Application threads blocked until data is available

• Transmit too many bits (sequence #, ack, re-transmission)• Tied with multi-threaded architecture

• TinyOS solution: active messages


Active Message• Every message contains the name of an event handler• Sender

• Declaring buffer storage in a frame• Naming a handler• Requesting Transmission; exit• Done completion signal

• Receiver• The event handler is fired automatically in a target node

No blocked or waiting threads on sender or receiverBehaves like any other eventsSingle buffering


Send Messagechar TOS_COMMAND(INT_TO_RFM_OUTPUT)(int val){

int_to_led_msg* message = (int_to_led_msg*)VAR(msg).data;

if (!VAR(pending)) {

message->val = val;

if (TOS_COMMAND(INT_TO_RFM_SUB_SEND_MSG)(TOS_MSG_BCAST, AM_MSG(INT_READING), &VAR(msg))) {

VAR(pending) = 1;

return 1;

}

}

return 0;

}

msg buffer

access appln msg buffer

cast to defined format

mark busy

application specific ready check

build msgrequest transmission

destination identifier

get handler identifier

Power Managerlu/cse467s/slides/power3_wsn1.pdf · 2012. 2. 2. · Chenyang Lu CSE 467S 5 ACPI...

Documents

Transcript of Power Managerlu/cse467s/slides/power3_wsn1.pdf · 2012. 2. 2. · Chenyang Lu CSE 467S 5 ACPI...