[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] TinyOS Telecon Notes 8/31/05

[Joe Polastre]

Let me propose an alternative method:

Components automatically return to their lowest power state after a
timeout.  If you want to keep the component running, you must "ping"
it.  I've been experimenting with this method and it is much more
robust and effective than anything we have in TinyOS 1.x today, and
its simple to implement.

My worry with the "fan out" approach is: What happens if I forget to
include a component?  This solution potentially gets very fragile.

-Joe

On 9/4/05, Philip Levis <pal at cs.stanford.edu> wrote:
> On Fri, 2005-09-02 at 12:08 +0200, Joe Polastre wrote:
> 
> > I've measured that the scheduler idle loop in TinyOS 1.x takes 30us,
> > so the extra 20us to check the power state isn't that bad.  If you can
> > get down that idle loop, then I'll buy the argument that the 20us is
> > critical ;)
> >
> 
> A 40% reduction isn't worth pursuing? I'll also bet money that the 2.x
> scheduler idle loop will be shorter than the 1.x. (If it isn't now, it
> should be and I'll make it so.:) All those pointer operations in 1.x
> really were expensive. )
> 
> > Phil, basically you're proposing that we keep the HPLPowerManagementM
> > with adjustPower() where adjustPower() sets a dirty bit that is
> > checked when the node goes to sleep.
> 
> If you take a look at the telecon notes, there's a bit more going on.
> One issue brought up is the possible need to override this automagic
> calculation, e.g., due to a desired minimum wakeup latency. There's also
> the question of per-transition pin reconfiguration (Martin's comments on
> the mica flash pins).
> 
> That being said, IIRC, this was actually Rob's suggestion. I'm of the
> opinion that a fanout call to all HPL components to request their
> minimum power state (with the combine function taking the highest power
> level) is a better approach, for a bunch of reasons. Rob had some
> reservations about the efficiency of such an approach, though, so
> barring a good performance evaluation demonstrating that the callout
> isn't an issue, we're continuing with the current single big mostly
> omniscient function approach.
> 
> Phil
>


_______________________________________________
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