Chenyang Lu CSE 467S 1
Power Manager
Chenyang Lu CSE 467S 2
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 …
Chenyang Lu CSE 467S 3
Advanced Configuration and Power Interface (ACPI)Open standard for power management services.
Hardware platformdevices, processor, chipset
devicedrivers
ACPI BIOS
OS kernel
applicationspower
management
Chenyang Lu CSE 467S 4
System States
Chenyang Lu CSE 467S 5
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
Chenyang Lu CSE 467S 6
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
Chenyang Lu CSE 467S 7
Reduce power in working state
Chenyang Lu CSE 467S 8
Holistic View of Power Consumption• Instruction execution (CPU)• Cache (instruction, data)• Main memory• Other: non-volatile memory, display,
network interface, I/O devices
Chenyang Lu CSE 467S 9
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
Chenyang Lu CSE 467S 10
Optimize Memory System• Different instructions Different energy
consumption• Energy drain: register << cache (SRAM) <<
memory (DRAM)→Most energy reduction comes from
optimizing memory system
Chenyang Lu CSE 467S 11
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.
Chenyang Lu CSE 467S 12
Impacts of Cache Size
Chenyang Lu CSE 467S 13
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!
Chenyang Lu CSE 467S 14
Wireless Sensor NetworksA Quick Overview• sensors + microprocessor + wireless
Berkeley Smart Dust
Chenyang Lu CSE 467S 15
Hardware Technology
Chenyang Lu CSE 467S 16
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
Chenyang Lu CSE 467S 17
MICA Motes• Radio Communication: 40 Kbps max• Commercial-off-the-shelf components
1’’X1’’
Chenyang Lu CSE 467S 18
Smart Dust• Current: 5 mm; in ten years: 1 mm float in
the air!• Radio?
• Nowhere to put antenna!• Require complex circuits energy-inefficient
Chenyang Lu CSE 467S 19
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
Chenyang Lu CSE 467S 20
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
Chenyang Lu CSE 467S 21
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.
Chenyang Lu CSE 467S 22
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 …
Chenyang Lu CSE 467S 23
Great Duck Island Habitat Monitoring• Usage patterns of burrows• Burrow and environmental
changes• Differences between
nesting areas and others
Chenyang Lu CSE 467S 24
Chenyang Lu CSE 467S 25
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
Chenyang Lu CSE 467S 26
Great Duck Island Tiered Architecture
http://www.greatduckisland.net
Chenyang Lu CSE 467S 27
Mote and TinyOS
Chenyang Lu CSE 467S 28
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
Chenyang Lu CSE 467S 29
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
Chenyang Lu CSE 467S 30
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
Chenyang Lu CSE 467S 31
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)
Chenyang Lu CSE 467S 32
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
Chenyang Lu CSE 467S 33
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
Chenyang Lu CSE 467S 34
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
Chenyang Lu CSE 467S 35
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
Chenyang Lu CSE 467S 36
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
Chenyang Lu CSE 467S 37
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
Chenyang Lu CSE 467S 38
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
Chenyang Lu CSE 467S 39
Receiving a message
Timing diagram of event propagation
Chenyang Lu CSE 467S 40
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
Chenyang Lu CSE 467S 41
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
Chenyang Lu CSE 467S 42
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
Top Related