[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] Thoughts on the power management proposal

[Philip Levis]

On Aug 17, 2005, at 4:14 PM, Robert Szewczyk wrote:

> Hi Martin,
>
> Thanks to my people on the inside, I've read through your power  
> management proposal.  I think there are a number of things to work  
> through here:
>
> 1. how do we manage the power state of the microcontroller?
> 2. how do we manage the power state of individual device drivers?
> 3. how do we manage the power state of the overall system at runtime?
> 4. how do we manage the default power state?
>
> I think once you separate these concerns you'll have a much clearer  
> picture of what problems you're trying to address, and where.  The  
> current philosphy of power management in TinyOS 1.x is that:
> 1. the processor runs at full speed, powers down into the lowest  
> power mode that will not interfere with the functioning of the  
> system.  On Telos/Tmote devices, the logic that computes the power  
> state is a part of the TinyOS task idle loop; on Mica* devices it  
> is precomputed with HPLPowerManagement.
> 2. Individual device drivers change the power state through  
> StdControl/SplitControl interfaces.  SplitControl was designed  
> explicitly to address the issues that come up with devices that  
> take a while to power up or power down.
> 3. Right now, there is no standardized way of explicitly managing  
> the power state of the entire system.  At some point, there was a  
> component called ServiceScheduler that would start and stop system  
> services according to a paticular schedule.
> 4. default power state (pin directions and levels) is proscribed by  
> platform.h, and, unfortunately does not allow for systematic  
> changes on a per sensor board basis.
>
> This system has a couple of shortcomings: it is not all that clear  
> to a novice user how to put the mote into a low power mode (the  
> behavior is implicit; there is no component that the application  
> could actuate),  the device drivers have only two power modes (I  
> think it is an open question whether we need more), and the whole  
> system does not really account for the wakeup latency (in the case  
> of a microcontroller it is a larger problem on AVR-based platforms  
> than on MSP430; but the design may need to address that).
>
> It is worthwhile to spend effort on creating a couple of components  
> that would give users a flavor for global power policy  
> implementation: perhaps a component that shows how to do duty  
> cycling of a single device (go from a continuous sampling to  
> infrequent duty cycling), maybe another component that does shows  
> how to do something on a synchronized network-wide scale.
>
> As for your pin directions example:  I believe it would make sense  
> to integrate some pin-setting state into each sensorboard  
> description file.  That gets you reasonable defaults that allow for  
> inclusion of a subset of drivers.  Each device driver does a bit of  
> extra intialization to get its HW into functional state; perhaps  
> that too needs to always be included in the sensor board  
> initialization (the one case that comes to mind is the flash that's  
> on Telos rev. B: the chip needs to be sent a command to go into low  
> power mode).  THe start/stop methods need to include code for  
> managing the power state of the device; part of that task is the  
> management of pin levels and directions.
>
> Your sensor example is actually fairly interesting if you consider  
> the following case: suppose you have a sensor that takes 2 seconds  
> to warm up; its driver implements start, stop, and sampling methods  
> correctly.  The application samples the sensor periodically.  Now,  
> the power states of that sensor may look very different when you  
> tell it to sample 10 times a second vs. 1 time per minute.  How  
> should this latency and sampling rate be embedded in the individual  
> components?  How should this be presented to the developer or  
> network manager?  Perhaps that points to another little power mgmt  
> policy component: it would encapsulate the sampling rate with the  
> startup info, and would internally manage the sensor; from the  
> outside world it could look like a getDataContinous from the old  
> ADC interface.
>
> Another thing to keep in mind would be to what extent can the start/ 
> stop methods be overlapped.   But that may be a topic for the  
> ensuing discussion.
>
> As for your question #2: it was done to minimize the race condition  
> between the empty task queue and sleep(at the time I thought it was  
> the way to go, but I'm no longer convinced of that); that race  
> condition was fixed by David Gay a few months ago. On Telos  
> platform, the sleep mode calculation was done in the task queue  
> loop, just like in your example.
>

There was some discussion on Martin's proposal, which is written up  
in the telecon notes. You can get them online; I'll send you a copy  
in a follow-up message.

I think the big question here is the tradeoff between explicit and  
implicit power scheduling. On one hand, the idea of a global power  
management system seems useful; on the other, it raises all sorts of  
compatibility issues in a component system. For example, while an  
application might think that it should turn everything off, a service  
it uses may need to take a few ADC samples (or send a few packets).

Your idea about information encapsulation is right on, and this was  
something we talked about a little. The notion is that, at the lowest  
level, power management should be in terms of {Std,Split}Control. 
{start,stop}(). One can easily layer heuristics on top of this: OSKI,  
for example, uses the Service interface to have an OR model for  
anything using a given software abstraction. To take a sensor as  
another (as of yet fictional) example, one could write a generic  
module that sits on top of a sensor but does not provide a Control  
interface. When a component samples the sensor, this module powers it  
up, samples, starts a timer, and signals the sample. If no other  
sample request arrives before the timer fires, it powers down the  
sensor.

However, we should really try to avoid enforcing particular energy  
conservation policies on applications, besides things that the OS can  
do safely without disrupting app behavior (e.g., the scheduler sleep  
loop). The timeout case above, for example, is good for applications  
with slow start sensors, flexibility in sampling jitter, and sample  
in bursts. It would really stink for applications that need precisely  
timed samples at very regular intervals, especially if the sensor  
timeout is (interval-1).

Phil

-------

"We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time."

- T. S. Eliot,  'Little Gidding'

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg