Marcin Miete Based on K. Klues, V. Handziski, C. Lu, A. Wolisz, D. - PowerPoint PPT Presentation

Integrating Concurrency Control and Energy Management in Device Drivers Marcin Mieteń Based on K. Klues, V. Handziski, C. Lu, A. Wolisz, D. Culler, D. Gay, and P. Levis: “Integrating Concurrency Control and Energy Management in Device Drivers ,” in Proceedings SOSP 2007, Stevenson, WA, USA, October 2007.

First look at the problem  Concurrency Control of I/O operations  Energy Management – power state of devices is determined by pending, asynchronous I/O requests

Sensornets – motivation  Energy management is a critical concern in wireless sensornets (small source of power, must run from months to years).  First generation sensornet Oses (TinyOS, Contiki, Mantis)  Push all energy management to the application  Optimal energy saving at cost of application complexity.

● ICEM ( Integrated Concurrency Control and Energy Management)  A device driver architecture that enables simple, energy efficient wireless sensornet applications.  Simple API  Sensornet applications don't have to be responsible for all power management  Implemented in TinyOS 2.0

Energy management  OS can improve energy efficiency by putting peripherals into low power modes and dropping process to a sleep state when idle.  We have many researches about saving energy in OS but...  Most modern operating system still use very simplistic energy management policies.

Hardware  T2 on the telos  8MHz 16 bit CPU  250kbps 802.15.4 radio  2 MB external flash  10kB of RAM

What we have  6 major I/O devices (sensors)  Possible Concurrency: I2C, SPI, ADC  Energy management ­ turn on peripherals only when needed

Concurrency opportunities  I2C –2 digital sensors use it  ADC – 2 analog sensors use it  OS can concurrently sample 1 digital and 1 analog sensor  Radio only need a SPI bus when loadin a packet into transmit memory  In MSP 430 tree bus protocols I2C, SPI and UART share a common set of I/O pins

Energy management  In many OSes energy efficiency comes at the cost of application code complexity. Many code lines with cases such as: “if forwarding a packet, defer powering down”  ICEM – allows a sensornet OS to automatically minimize energy consumption without requiring additional explicit information from an application.  500 lines of code → using ICEM it would by fewer then 50 lines

Running example

Hand-Tuned vs ICEM ICEM energy efficient >= 98,4% hand tuned implmentation

● Concurrency PRODUCER CONSUMER Every 5 minutes: Every 12 hours: Write prior samples For all new log entries: Sample photo active Send current sample Sample total solar Read next sample Sample temperature Sample humidity  Depending on the hardware OSes can do sampling operations concurrently.  Concurrency reduces how long the producer part of the application stays awake when sampling.  To achieve it producer's 5 operations should be non blocking or run one thread per operation.  Sensornets usually use saplit-phase non­blocking operations because of limited RAM

Siplit-phase operations  Asynchronous I/O with one difference: Application application making split­phase receives explicit notifications (upcall) Read() readDone() about its completion. Driver  It allows a device driver to know exactly when an application has been I/O I/O request interrupt notified about the completion of an I/O event.  ICEM uses this knowledge to control device's power state.

ICEM concurrency classes  Virtualized  Dedicated  Shared

● Virtualized  Support multiple users  Buffer requests  Give clients the appearance of independence  For higher level services that can tolerate latency.  For example: data­link packet sender is virtualized driver.  Buffers requests and services them with a round­ robin policy.  Driver can control power stated (power on when pending requests)

Dedicated Dedicated  Support single user  For low­level hardware resources  Give single user complete control over requests and energy management  May provide explicit power control interface.

Shared  Provide explicit concurrency  Users must contend for the driver through lock  Calling commands on shared drivers without holding lock is an error. Some clients are trusted (unchecked) and some are not trusted (checked)  Buffer lock request (Virtualized drivers buffer functional request e.g. send a packet)  Arbiter is an ICEM library component.

Split-phase Power Locks

Split-phase Power Locks  ICEM use shared drivers with power locks  Power locks couple energy, configuration and concurrency management.  Turn device off if lock falls idle.  Allow a client to specify a device configuration before an arbiter grants him the lock.  Lock must be split­phase (TinyOS does not have blocking calls)  Each lock in system has set of candidate holders (fixed at compile­time … TinyOS can create components only in compile­time)

Split-phase Power Locks  Lock request are non­blocking (split­phase)  We can request several locks in parallel. Upcalls for lock could come in different order then requests. It could cause deadlock.  Client 1: lock1, lock2, ?(upcall1 and upcall 2) Client 2: lock1, lock2, ?(upcall1 and upcall 2) upcall 1 to client 1, upcall 2 to client 2 == deadlock

ICEM Component Library  ICEM provides a library of components that allow to implement power locks in device drivers.  The library has three types of components:

Power Lock Power Lock

Power Lock components

Arbiter  Power locks core component  Provide split­phase lock interface that arbitrates between outstanding requests  Determines its request queueing policy(RR or FCFS)  When no one use lock Arbiter grant it to Default owner (DO). When DO has lock and somebody want to get lock then arbiter sends callback to DO.  Before granting lock for user (and sending callback to him) Arbiter use corresponding configuration interface. 

Power Managers  Implement the DefaultOwne interface and use explicit power interfaces.  Specifies a power lock's energy management policy.  2 power manager policies: immediate and deferred  3 interfaces to control energy  Device on ↔ Power Managers has not lock. Client Interfaces to control energy: request lock Start() ● StdControl (single-phase control) relese lock ● SplitControl (split-phase control) startDone()

Configurators  Implementing Configuration interface that arbiter use  Allow clients to run some preambles before granting locks.  One implementation can serve the same code preamble for many clients.  Configurators are device specific  Mega128 ADC, MSP430 ADC, SPI, USART, I2C

Power Lock components

ADC driver example 1. Instantiate ADC  RR arbiter client and his Config. 2. request ADC 3. Request lock sample 11. relese lock 8. Lock granted 10. sample 9 . Request done sample 4. Request 7. Configure ADC lock 6. relese lock 5. Turn on

USART example

Energy consumption Serial+ - Optimal I/O ordering  Serial- - the worst case I/O ordering 

Lifetime

Lifetime

Livetime

ICEM waste energy  Stays in active mode due to power lock  Timeouts (hand­tuned imp. knows to turn off immediately when device is no more needed)  Additional 1800 cycles per sample due to arbiter

Sleep Energy Management  The second part of an efficient energy management strategy is to control the sleep state of node's microcontroller.  Microcontrollers have spectrum of low power modes.  Power mode has to be enough high to run all actually used peripherals.  Computing the lowest power state of microcontroller requires system width­ information and can be complex and costly.

ICEM Sleep Energy Management  Every controller have function calculating the lowest safe power state (based on enabled devices)  OS compute this function only when dirty bit is on  Drivers set dirty bit when they touch hardware.  Drivers can specify a minimum safe sleep state ­ hook

Questions?