Week 11: ICEM

Integrated Concurrency and Energy Management (ICEM)

ICEM is a device driver architecture that enables simple, energy efficient wireless sensornet applications. Authors of the paper challenge the idea that sensornets cannot have standardized OS with simply API to manage the power and concurrency. The main idea is to deviate from the standard approach— hand-tuning the whole nesC code for power optimizations. ICEM offers set of tools that allows you to build a much shorter code and still manage power efficiency: Virtualized, Dedicated and Shared drivers. These tools leverage on the concurrency knowledge that application provides. The event-driven nature of the TinyOS uses split-phase operations that provide the valuable information i.e. when each operations ends it will inform that it ended using back-call, which is the main difference between asynchronous I/O that is used in threaded operating system. With such knowledge, ICEM drivers can efficiently turn and off underlying devices without wasting energy. However, there is another complication that might arise when some operations need to make series of atomic operations or require access to several peripherals at the same time. To handle these situations, ICEM creates the hardware lock abstraction in non-blocking (non threaded) environment using “Power Locks.” These locks are implemented by the shared drivers because they buffer “lock” requests, while virtualized drivers buffer “functional” requests. Thus, both drivers provide concurrency and energy management to their clients using them. Since dedicated drivers don't have such support, ICEM also provides them set of interfaces to allow building the system. They are part of “Lock” interface and include: StdControl, SplitControl and AsynStdControl (where Std is used for immediate access, Split for deferred access and AsyncStd for immediate hardware interrupts). As for the shared driver's Power Locks, ICEM provides the whole component library to implement them: arbiters, power managers and configurators.

The strength of the ICEM paper is definitely the depth of coverage of all the design components. Since complexity of the energy management is hidden from the application with the use of ICEM, it is important to understand how all of the drivers and components work behind ICEM. Thus, thorough explanation of why certain drivers were made and how they create abstractions is necessary. With such knowledge in mind, nesC developer will be able to understand why in some cases hand-tuned implementation is superior to ICEM implementation and in some cases equivalent. For example, flexibility of ICEM comes with the price of configuration requirements of some of its peripherals before arbiters can use them to make sure the drivers can interact with them. Since not all peripherals require configuration, a future consideration to ICEM could be to make configurations an option by providing a flag for it in its library components.

The other strong aspect of this paper is the scope of evaluations made to prove ICEM's efficiency in providing energy management. It is imperative for the sensornet developer to understand what ROM and RAM overhead library components are causing, which is very delicately done by measuring the current drawings at different power states and peripheral operations. With such experiment, authors identified the most expensive operation, which was obviously granting a request. By simply taking an integral of current drawing, energy consumption was identified. Using this measurement model, different implementation samples were made to compare ICEM against blocking threaded with different sample rate and hand tuned implementation. As predicted, ICEM scored within 1.6% of efficiency to the best hand tuned implementation of our example application. What makes this discovery powerful is the fact that 68 nesC lines of code were written instead of 400 lines, making ICEM definitely the strong candidate for application where 1.6% deviation from perfect is allowed. The only drawback of ICEM that has been left out as the open question in this paper is the deadlock handling. Failure to address this issue might cause system design (with peripherals sending a lot of parallel requests to acquire access to several pieces or making series of atomic operations) to fail. The question on how to handle deadlock situations will be asked in class.

Class discussions:

One of the first discussion was the ability of ICEM to deal with deadlock situations. Students suggested that static analysis will be the only feasible solution that will prevent deadlock to happen after all. One of the main arguments was the fact that nesC is built in a similar way. Thus, having deadlock prevention mechanism working in a similar fashion will not be ugly in terms of overall system design.

The next discussion questioned the completeness of the power lock queuing logic. Student asked whether power locks can be given priority or not. Since there is no direct control of prioritizing the locks, it was concluded that it will be the matter of creating work around using the ordering scheme inside the queue such as the round robin or first-come first-served approach.

The basic Lock Interface question was asked about the difference between StdControl and AsyncStdControl. In other words, what is the difference between them and which one is invoked in what kind of situations. Simple explanation was given by drawing parallel with the need of hardware interrupts. For example, if bits are received on the wire, hardware interrupt is needed to handle it immediately, so that the next set of bits will not override and loss will occur. Similarly, AsyncStdControl is used for hardware interrupts and StdControl is used for those devices that could be taken control immediately without startup latencies. After that, another interface question was asked about the role of the DefaultOwner, which is simply the default client that gets the power lock when no one else needs it. This way, ICEM controls the energy management by turning off the devices when DefaultOwner is holding the lock and turning on conversely.

The major drawback the whole class agreed upon is the need for configuration before any power lock can be granted to the client. One of the students argued that such approach proves to be inflexible in real life implementation. However, presenter argues that extensive evaluation showed that ICEM works great with the most popular platforms without having problems in configuring some motes (for example to switch to certain modes in their buses) before obtaining locks.

Overall, the class was pleased with the quality of the paper and the graph that shows the comparison of energy management results comparing ICEM to the perfect hand tuned implementation. The general impression was that the semester long discussion about optimizing idle listening was the complete waste of time since ICEM was able to score within 1.6% of the best implementation.