Integrating Concurrency Control and Energy Management in Device Drivers by Klues et. al.
Triage: Balancing Energy and Quality of Service in a
Microserver, By Banerjee et. al.
Last Tuesday, we discussed two papers focused on novel approaches to increasing power efficiency in wireless sensor networks. One paper, Integrating Concurrency Control and Energy Management in Device Drivers by Klues et al. focused on building a wireless sensor net OS model which integrates power management at the driver level, automatically turning off peripherals which are not needed. The other paper, Triage: Balancing Energy and Quality of Service in a Microserver, focuses on a specific subset of applications for sensor nets in which resource-constrained nodes are interspersed with more powerful micro-servers. To save power, Triage presents a novel architecture for these microservers in which a low-power node recieves and schedules tasks to be run on a more powerful stargate-class mote, allowing the more power hungry stargate to be turned off much of the time.
We began by focusing on the ICEM paper by Klues et. al. A fundamental underlying argument in ICEM is that much of the inefficiency of existing sensor network systems results from the inefficient handling of concurrency among different parts of an application. To remedy this, ICEM offers a driver system based on the concept of “Power Locks.” To support different types of hardware peripherals, ICEM offers three types of drivers: virtualized, dedicated, and shared. Virtualized drivers encapsulate all the buffering and per-client state maintenance, exposing only a simple functional data path to the application. Dedicated drivers, on the other hand, allow only a single user at a time, which is essential when dealing with low-level hardware control such as turning on or off an LED using a pin on the microcontroller. The third type, shared drivers, permit multiple users but require them to handle concurrency explicitly by trying to acquire a lock on the driver. In a nutshell, ICEM uses the low-level information gained from these driver interfaces to make simple inferences about the future expected concurrency for a given peripheral, and then tries to efficiently put it to sleep at times when it is not needed.
While some thought that the emphasis on deeply integrating power management into the OS was a step in the right direction, there was a good deal of discussion as to whether this approach would truly offer as many gains as they suggest in terms of application performance. A key issue here is the problems created by out-of-phase recurring tasks. For example, if two components of an application sample the ADC every 10 seconds, it would be most efficient to have them synchronized such that each samples one after the other, meaning the ADC would only turn on every 10 seconds for a few cycles. If, however, the components were out of phase such that component one sampled at say time t=n*10, and component two sampled at t=n*10+5, then the ADC is effectively turned on every five seconds which is considerably less efficient. Additionally, several people felt that ICEM had limited utility for applications in which the main power consumption came from a source other than the hardware peripherals, such as PDA class devices.
With regard to the Triage application, there was some discussion as to the applicability of the design to real-world appliacations. A number of people initially felt that the dual hardware approach in a less powerful and more energy efficient node controlled the scheduling of the more power-hungry an more powerful CPU was an innovative approach, but the discussion brought out several of points which raised doubt about its utility. It quickly became apparent that the motivation for the Triage design was based heavily on several assumptions, namely that:
- The Microserver can be shutdown much of the time
- Messages have to be small (since a lower-power, less powerful node recieves and processes them)
- The Microserver will recieve tasks from other nodes in the network via radio (as opposed to from the internet, or a central hub)
The last assumption, in particular, seems to me to limit the potential utility of the Triage design: it necessitates an application in which the resource-constrained nodes do not simply relay data to the microserver, but actually send queries which require use of the heavy processing on the stargate-class device. I can imagine situations in which this might be useful, such as using microservers to offer services to mobile nodes in a ubiquitous computing context, but this type of application is never mentioned by the authors.
