critiques - washington university in st. louislu/cse521s/slides/icem.pdficem: integrated concurrency...

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


10

Saving energy is a complex process





11

Saving energy is a complex processA little application knowledge can help us a lot




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


Flash

Consumer

Sensors Radio


Producer


19


Flash

Consumer

Sensors Radio


Producer


20


Flash

Consumer

Sensors Radio


Producer


21


Flash

Consumer

Sensors Radio


Producer


22


Flash

Consumer

Sensors Radio


Producer


23


Flash

Consumer

Sensors Radio


Producer


24


Flash

Consumer

Sensors Radio


Producer


25


Flash

Consumer

Sensors Radio


Producer


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



Code Complexity

28



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


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


Lock

Functional

Power Locks

38

Dedicated Driver

Power Locks

Power Control


Lock

Functional

Power Locks

39

Dedicated Driver

Power Locks

Power Control


Lock

Functional

Power Locks

40

Dedicated Driver

Power Locks

Power Control


Lock

Functional

Power Locks

41

Dedicated Driver

Power Locks

Power Control


Lock

Functional

Power Locks

42

Dedicated Driver

Power Locks

Power Control


Lock

Functional

Power Locks

43

Dedicated Driver

Power Locks

Power Control


Lock

Functional

Power Locks

44

Dedicated Driver

Power Locks

Power Control


Lock

Functional

Power Locks

45

Dedicated Driver

Power Locks

Power Control


Lock

Functional

1

2

3

Power Locks

46

Dedicated Driver

Power Locks

Power Control


Lock

Functional

Lock - - -

Power Locks

47

Dedicated Driver

Power Locks

Power Control


Lock

Functional

- - -

Power Locks

48

Dedicated Driver

Power Locks

Power Control


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


Component Library

51

Lock

Power Control


Arbiter

Arbiter Configure

Default Owner

Configurator Power Manager

Component Library

52

Power Control


Arbiter

Arbiter Configure

Default Owner


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


Arbiter

Arbiter Configure

Default Owner


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


Arbiter

Arbiter Configure

Default Owner


Lock

n  Implement ArbiterConfigure interface

n  Call hardware specific configuration from dedicated driver

Component Library

55

Power Control


Arbiter

Arbiter Configure

Default Owner


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



57

Msp430 USART

Power Control

Functional Configuration



58

Arbiter

Immediate Power Manager

SPI User

Msp430 USART

SPI Configurator

Power Control


Lock



59

Uart Configurator

Arbiter

Immediate Power Manager

SPI User

Msp430 USART

SPI Configurator

Uart User

I2C User I2C Configurator

Power Control


Lock

Virtualized Driver Example

Ø  Flash Storage

60

Arbiter

Immediate Power Manager SPI User

Log User

Flash Driver

Log Virtualizer

Lock

Power Control

Functional


Ø  Flash Storage

61

Arbiter


Log User

Flash Driver

Log Virtualizer

Lock

Power Control

Functional


Ø  Flash Storage

62

Arbiter


Log User

Flash Driver

Log Virtualizer

Lock

Power Control

Functional


Ø  Flash Storage

63

Arbiter


Log User

Flash Driver

Log Virtualizer

Lock

Power Control

Functional


Ø  Flash Storage

64

Arbiter


Log User

Flash Driver

Log Virtualizer

Lock

Power Control

Functional

- - -


Ø  Flash Storage

65

Arbiter


Log User

Flash Driver

Log Virtualizer

Lock

Power Control

Functional


Ø  Flash Storage

66

Arbiter


Log User

Flash Driver

Log Virtualizer

Lock

Power Control

Block Virtualizer

Block User


Ø  Flash Storage

67

Arbiter


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


Flash Consumer

Sensors Radio


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 -


71


0

25

50

75

100

288 Samples 2 Sends

E (m

As) Hand Tuned



72


0

25

50

75

100

288 Samples 2 Sends

E (m

As) Hand Tuned


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


75


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.

critiques - washington university in st. louislu/cse521s/slides/icem.pdficem: integrated concurrency...

Documents