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

[mturon at xbow.com]

Czesc Rob,

Your input into this power management discussion is very helpful; I am
curious what you think of the following modified proposal:

1) The scheduler notifies the HPL layer that sleep is imminent, and requests
the minimal tolerable state (dgay mentioned this last meeting).  This HPL
notification can be forwarded to the MCU and platform scope.

    1) scheduler   scheduler --> __nesc_atomic_sleep 
           \     / 
    2)    MCU   MCU         
             \ /
    3)    platform       

Note: your "adjustPower" code would then be implemented in the individual
HPL subsystems.

I agree with Vlado that the MCU should be able to sleep very quickly with
minimum dependencies on subsystems.  The current implementation of
__nesc_atomic_sleep does this with raw register reads in atomic context.
This looks like HPL code that is not done within the HPL -- back to peeking
and poking assembly registers...  I am suggesting pulling the subsystem
checks out of atomic context, and implementing them in a subsystem HAL that
queries the HPL.

typedef uint8_t power_state_t;

[scheduler]

while (1) {
      run tasks
      <empty>

      // query subsystems for minimum state
      power_state_t sleepState = HALPwrMgr.sleep();

      __nesc_atomic_sleep(sleepState);
}

[chips/MCU]
     HALPwrMgr.sleep() {
        power_State_t state = DEEP_SLEEP;

	// or this can be done with fan-out wiring if order is arbitrary
	state  = HPLTimer.sleep();
	result = (state > result) ? state : result;
	state  = HPLADC.sleep();
	result = (state > result) ? state : result;
	//...

	return result;
     }

2) Sensors are not involved in this notification; they use a component
wrapper to power up on .getData and "spin down" after some timeout.  Both
you and Phil describe something similar to this design.

Regards,     
Martin 

P.S.  I'll be in Asia next Wednesday, so I may not be able to participate in
the meeting.

__________________________________________________
Martin Turon  |  Crossbow Technology, Inc.

-----Original Message-----
From: tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU
[mailto:tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU] On Behalf Of
Robert Szewczyk
Sent: Friday, August 19, 2005 3:08 PM
To: 'Philip Levis'
Cc: tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
Subject: RE: [Tinyos-2.0wg] Thoughts on the power management proposal

Thanks for the pointer to the discussion.  

What are you getting at in the last paragraph?  I never said that the system
should provide these global policies for energy conservation.  I do believe
that the system out to codify the interfaces and semantics associated with
the power management mechanisms; that's roughly what's there right now.
What's missing is a few components that actuate these mechanism in a useful
manner; unless these are provided, nobody will actually be able to use these
mechanisms (Martin's original proposal is a clear reflection of that
problem).    

Rob
 

-----Original Message-----
From: Philip Levis [mailto:pal at eecs.berkeley.edu] 
Sent: Thursday, August 18, 2005 9:42 AM
To: Robert Szewczyk
Cc: tinyos-2.0
Subject: Re: [Tinyos-2.0wg] Thoughts on the power management proposal

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
_______________________________________________
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