CritiquesØ 1/2 page critiques of research papersØ Due at 10am on the class day (hard deadline)
Ø Email Dingwen [email protected] in plain txtØ Back-of-envelop notes - NOT whole essays
Ø Guidelines: http://www.cs.wustl.edu/%7Elu/cse521s/critique.html
Ø Critique #2Ø Due on 9/24
Ø M. Buettner, G.V. Yee, E. Anderson and R. Han, X-MAC: a Short Preamble MAC Protocol for Duty-Cycled Wireless Sensor Networks, ACM Conference on Embedded Networked Sensor Systems (SenSys), November 2006.
1
Integrating Concurrency Control and Energy Management in Device Drivers
ChenyangLu
Why worry about energy?
No Moore’s Law in batteries: 2-3%/year growth!
Processor (MIPS)
Hard Disk (capacity)
Memory (capacity)
Battery (energy stored)
0 1 2 3 4 5 6
16x
14x
12x
10x
8x
6x
4x
2x 1x
Improvement (compared to year 0)
Time (years)
Intelvs.Duracell
3
4
The Mote Revolution: Low Power Wireless Sensor Network Devices, Joseph Polastre, Robert Szewczyk, Cory Sharp, David Culler, Hot Chips 16.
Low-Power Sensor Platforms
Power State TransitionsØ System view when switching from sleep to active
5
Source: Joseph Polastre, Robert Szewczyk, Cory Sharp, David Culler. The Mote Revolution: Low Power Wireless Sensor Network Devices. In Hot Chips 16, 2004.
OverviewØ Concurrency Control:
q Concurrency of I/O operations alone, not of threads in generalq Synchronous vs. Asynchronous I/O
Ø Energy Management:q Power state of devices needed to perform I/O operations
q Determined by pending I/O requests using Asynchronous I/O
6
OS Flash Driver Physical Flash
read()
write()
setPowerState()
Application
read() write() read() read()
Overview
7
Ø Concurrency Control:q Concurrency of I/O operations alone, not of threads in generalq Synchronous vs. Asynchronous I/O
Ø Energy Management:q Power state of devices needed to perform I/O operations
q Determined by pending I/O requests using Asynchronous I/O
The more workload information an application can give the OS, the more energy it can save.
MotivationØ Difficult to manage energy in traditional OS
q Hard to tell OS about future application workloadsq API extensions for hints?
8
Existing OS Approaches
Ø Dynamic CPU Voltage Scalingq Vertigo - Application workload classes
q Grace OS - Explicit real-time deadlines
Ø Disk Spin Downq Coop-IO - Application specified timeouts
9
Existing OS Approaches
10
Saving energy is a complex process
Ø Dynamic CPU Voltage Scalingq Vertigo - Application workload classes
q Grace OS - Explicit real-time deadlines
Ø Disk Spin Downq Coop-IO - Application specified timeouts
Existing OS Approaches
11
Saving energy is a complex processA little application knowledge can help us a lot
Ø Dynamic CPU Voltage Scalingq Vertigo - Application workload classes
q Grace OS - Explicit real-time deadlines
Ø Disk Spin Downq Coop-IO - Application specified timeouts
Sensor Networks
Ø Domain in need of unique solution to this problemq Harsh energy requirementsq Very small source of power (2 AA batteries)q Must run unattended from months to years
12
Sensor Networks
Ø Domain in need of unique solution to this problemq Harsh energy requirementsq Very small source of power (2 AA batteries)q Must run unattended from months to years
Ø First generation sensornet OSes (TinyOS, Contiki...)q Push all energy management to the applicationq Optimal energy savings at cost of application complexity
13
ICEM: Integrated Concurrency and Energy Management
Ø Device driver architecture that automatically manages energy
Ø Introduces Power Locks, split-phase locks with integrated energy and configuration management
Ø Defines three classes of drivers: dedicated, shared, virtualized
Ø Provides a component library for building drivers
Ø Implemented in TinyOS 2.0 -- all drivers follow it
14
Advantages of ICEM
Ø Energy efficient – 98.4% as hand-tuned implementation
Ø Reduces code complexity – 400 vs. 68 lines of code
Ø Enables natural decomposition of applications
15
The TelosB PlatformØ Six major I/O devicesØ Possible Concurrency
q I2C, SPI, ADC
Ø Energy Managementq Turn peripherals on only when needed
q Turn off otherwise
16
Representative Logging Application
17
Every 12 hours: For all new entries: Send current sample Read next sample
Flash
Consumer
Sensors Radio
Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity
Producer
18
Every 12 hours: For all new entries: Send current sample Read next sample
Flash
Consumer
Sensors Radio
Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity
Producer
Representative Logging Application
19
Every 12 hours: For all new entries: Send current sample Read next sample
Flash
Consumer
Sensors Radio
Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity
Producer
Representative Logging Application
20
Every 12 hours: For all new entries: Send current sample Read next sample
Flash
Consumer
Sensors Radio
Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity
Producer
Representative Logging Application
21
Every 12 hours: For all new entries: Send current sample Read next sample
Flash
Consumer
Sensors Radio
Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity
Producer
Representative Logging Application
22
Every 12 hours: For all new entries: Send current sample Read next sample
Flash
Consumer
Sensors Radio
Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity
Producer
Representative Logging Application
23
Every 12 hours: For all new entries: Send current sample Read next sample
Flash
Consumer
Sensors Radio
Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity
Producer
Representative Logging Application
24
Every 12 hours: For all new entries: Send current sample Read next sample
Flash
Consumer
Sensors Radio
Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity
Producer
Representative Logging Application
25
Every 12 hours: For all new entries: Send current sample Read next sample
Flash
Consumer
Sensors Radio
Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity
Producer
Representative Logging Application
Code Complexity
26
Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I2C bus Log prior readings Start humidity sample Wait 5ms for log Turn off flash chip Turn off SPI bus Wait 12ms for vref Turn on ADC Start total solar sample Wait 2ms for total solar Start photo active sample Wait 2ms for photo active Turn off ADC Turn off voltage reference Wait 34ms for humidity Start temperature sample Wait 220ms for temperature Turn off I2C bus
Hand-Tuned Application
Code Complexity
27
Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I2C bus Log prior readings Start humidity sample Wait 5ms for log Turn off flash chip Turn off SPI bus Wait 12ms for vref Turn on ADC Start total solar sample Wait 2ms for total solar Start photo active sample Wait 2ms for photo active Turn off ADC Turn off voltage reference Wait 34ms for humidity Start temperature sample Wait 220ms for temperature Turn off I2C bus
Hand-Tuned Application
Code Complexity
28
Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I2C bus Log prior readings Start humidity sample Wait 5ms for log Turn off flash chip Turn off SPI bus Wait 12ms for vref Turn on ADC Start total solar sample Wait 2ms for total solar Start photo active sample Wait 2ms for photo active Turn off ADC Turn off voltage reference Wait 34ms for humidity Start temperature sample Wait 220ms for temperature Turn off I2C bus
Hand-Tuned Application
Code Complexity
29
Every 5 minutes: Log prior readings sample humidity sample total solar sample photo active sample temperature
ICEM Application Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I2C bus Log prior readings Start humidity sample Wait 5ms for log Turn off flash chip Turn off SPI bus Wait 12ms for vref Turn on ADC Start total solar sample Wait 2ms for total solar Start photo active sample Wait 2ms for photo active Turn off ADC Turn off voltage reference Wait 34ms for humidity Start temperature sample Wait 220ms for temperature Turn off I2C bus
Hand-Tuned Application
Split-Phase I/O Operations
Ø Implemented within a single thread of controlØ Application notified of I/O completion through direct upcallØ Driver given workload information before returning controlØ Example: read() à readDone()
30
Application
Driver
read() readDone()
I/O request I/O interrupt
void readDone(uint16_t val) { next_val = val; read(); }
ICEM Architecture
Ø Defines three classes of driversq Virtualized – provide only functional interface
q Dedicated – provide functional and power interfaceq Shared – provide functional and lock interface
31
Dedicated Device Drivers
Ø Provide Functional and Power Control interfacesØ Assume a single user
Ø No concurrency controlØ Explicit energy management
Ø Low-level hardware and bottom-level abstractions have a dedicated driver
32
Energy: Implicit Concurrency: None
Dedicated
Virtualized Device Drivers
Ø Provide only a Functional interfaceØ Assume multiple users
Ø Implicit concurrency control through buffering requestsØ Implicit energy management based on pending requests
Ø Implemented for higher-level services that can tolerate long latencies
33
Energy: Implicit Concurrency: Implicit
Virtualized
Shared Device Drivers
Ø Provide Functional and Lock interfacesØ Assume multiple users
Ø Explicit concurrency control through Lock requestØ Implicit energy management based on pending requests
Ø Used by users with stringent timing requirements
34
Energy: Implicit Concurrency: Explicit
Shared
ICEM Architecture
35
• Defines three classes of driversw Virtualized – provide only functional interfacew Dedicated – provide functional and power interface
w Shared – provide functional and lock interface
• Power Locks, split-phase locks with integrated energy and configuration management
Power Locks
36
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
Power Locks
37
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
Power Locks
38
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
Power Locks
39
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
Power Locks
40
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
Power Locks
41
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
Power Locks
42
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
Power Locks
43
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
Power Locks
44
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
Power Locks
45
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
1
2
3
Power Locks
46
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
Lock - - -
Power Locks
47
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
- - -
Power Locks
48
Dedicated Driver
Power Locks
Power Control
HW-Specific Configuration
Lock
Functional
- - -
ICEM Architecture
49
• Defines three classes of driversw Virtualized – provide only functional interfacew Dedicated – provide functional and power interface
w Shared – provide functional and lock interface
• Power Locks, split-phase locks with integrated energy and configuration management
• Component libraryw Arbiters – manage I/O concurrencyw Configurators – setup device specific configurations
w Power Managers – provide automatic power management
Component Library
50
Lock
Power Locks
Power Control
HW-Specific Configuration
Component Library
51
Lock
Power Control
HW-Specific Configuration
Arbiter
Arbiter Configure
Default Owner
Configurator Power Manager
Component Library
52
Power Control
HW-Specific Configuration
Arbiter
Arbiter Configure
Default Owner
Configurator Power Manager
Lock
n Lock interface for concurrency control (FCFS, Round-Robin)
n ArbiterConfigure interface automatic hardware configuration
n DefaultOwner interface for automatic power management
Component Library
53
Power Control
HW-Specific Configuration
Arbiter
Arbiter Configure
Default Owner
Configurator Power Manager
Lock
n Lock interface for concurrency control (FCFS, Round-Robin)
n ArbiterConfigure interface automatic hardware configuration
n DefaultOwner interface for automatic power management
- - -
Component Library
54
Power Control
HW-Specific Configuration
Arbiter
Arbiter Configure
Default Owner
Configurator Power Manager
Lock
n Implement ArbiterConfigure interface
n Call hardware specific configuration from dedicated driver
Component Library
55
Power Control
HW-Specific Configuration
Arbiter
Arbiter Configure
Default Owner
Configurator Power Manager
Lock
n Implement DefaultOwner interfacen Power down device when device falls idlen Power up device when new lock request comes inn Currently provide Immediate and Deferred policies
Shared Driver Example
Ø Msp430 USART (Serial Controller)q Three modes of operation – SPI, I2C, UART
56
Shared Driver Example
Ø Msp430 USART (Serial Controller)q Three modes of operation – SPI, I2C, UART
57
Msp430 USART
Power Control
Functional Configuration
Shared Driver Example
Ø Msp430 USART (Serial Controller)q Three modes of operation – SPI, I2C, UART
58
Arbiter
Immediate Power Manager
SPI User
Msp430 USART
SPI Configurator
Power Control
Functional Configuration
Lock
Shared Driver Example
Ø Msp430 USART (Serial Controller)q Three modes of operation – SPI, I2C, UART
59
Uart Configurator
Arbiter
Immediate Power Manager
SPI User
Msp430 USART
SPI Configurator
Uart User
I2C User I2C Configurator
Power Control
Functional Configuration
Lock
Virtualized Driver Example
Ø Flash Storage
60
Arbiter
Immediate Power Manager SPI User
Log User
Flash Driver
Log Virtualizer
Lock
Power Control
Functional
Virtualized Driver Example
Ø Flash Storage
61
Arbiter
Immediate Power Manager SPI User
Log User
Flash Driver
Log Virtualizer
Lock
Power Control
Functional
Virtualized Driver Example
Ø Flash Storage
62
Arbiter
Immediate Power Manager SPI User
Log User
Flash Driver
Log Virtualizer
Lock
Power Control
Functional
Virtualized Driver Example
Ø Flash Storage
63
Arbiter
Immediate Power Manager SPI User
Log User
Flash Driver
Log Virtualizer
Lock
Power Control
Functional
Virtualized Driver Example
Ø Flash Storage
64
Arbiter
Immediate Power Manager SPI User
Log User
Flash Driver
Log Virtualizer
Lock
Power Control
Functional
- - -
Virtualized Driver Example
Ø Flash Storage
65
Arbiter
Immediate Power Manager SPI User
Log User
Flash Driver
Log Virtualizer
Lock
Power Control
Functional
Virtualized Driver Example
Ø Flash Storage
66
Arbiter
Immediate Power Manager SPI User
Log User
Flash Driver
Log Virtualizer
Lock
Power Control
Block Virtualizer
Block User
Virtualized Driver Example
Ø Flash Storage
67
Arbiter
Immediate Power Manager SPI User
Flash Driver Lock
Power Control
Log User
Log Virtualizer Block Virtualizer
Block User
Applications
Ø Hand Tuned – Most energy efficientØ ICEM – All concurrent operations
Ø Serial + – Optimal serial ordering Ø Serial - – Worst case serial ordering
68
Every 12 hours: For all new entries: Send current sample Read next sample
Flash Consumer
Sensors Radio
Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity
Producer
Tmote Energy Consumption
69
Average energy consumption for application operations
Application Energy Consumption
70
Application energy with 5 minute sampling interval and one send batch every 12 hours
0
25
50
75
100
288 Samples 2 Sends
E (m
As) Hand Tuned
ICEMSerial +Serial -
Application Energy Consumption
71
Application energy with 5 minute sampling interval and one send batch every 12 hours
0
25
50
75
100
288 Samples 2 Sends
E (m
As) Hand Tuned
ICEMSerial +Serial -
Application Energy Consumption
72
Application energy with 5 minute sampling interval and one send batch every 12 hours
0
25
50
75
100
288 Samples 2 Sends
E (m
As) Hand Tuned
ICEMSerial +Serial -
Sampling Power Trace
73
Overhead of ICEM to Hand-Tuned Implementation = ADC Timeout + Power Lock Overheads
With 288 samples per day ≈ 2.9 mAs/day ≈ 1049 mAs/year
Insignificant compared to total 5.60% of total sampling energy 0.03% of total application energy
Expected Node Lifetimes
74
Expected Node Lifetimes
75
Expected Node Lifetimes
76
Evaluation Conclusions
Ø Conclusions about the OSq Small RAM/ROM overheadq Small computational overheadq Efficiently manages energy when given enough information
Ø Conclusions for the developerq Build drivers with short power down timeoutsq Submit I/O requests in parallel
77
ICEMIntegrated Concurrency and Energy Management
Ø Device driver architecture for low power devices
Ø At least 98.4% as energy efficient as hand-tuned implementation of representative application
Ø Simplifies application and driver development
Ø Questions the assumption that applications must be responsible for all energy management and cannot have a standardized OS with a simple API
78
K. Klues, V. Handziski, C. Lu, A. Wolisz, D. Culler, D. Gay and P. Levis, Integrating Concurrency Control and Energy Management in Device Drivers, ACM Symposium on Operating System Principles (SOSP'07), October 2007.