[Tinyos-host-mote-wg] [Tinyos-2.0wg] 08/24/2005 Telecon Notes
Kristin Wright
l.kristin.wright at gmail.com
Fri Sep 2 14:49:43 PDT 2005
-------------- next part --------------
Notes from 08/24/2005 TinyOS 2.0 Working Group
Phil Buonnadonna (Arched Rock), David Culler (Arched Rock), David Gay
(Intel Research, Berkeley), Vlado Handziski (TU Berlin), Phil Levis
(Stanford), Lama Nachman (Intel), Rob Szewczyk (Moteiv), Kristin
Wright (UCB)
08/24/2005 Agenda
-----------------
Agenda:
- pre2, again
- power mgmt, again (please read the email thread)
08/24/2005 Discussion Notes
----------------------------------------------------------
Pre2
-------
- phil and dgay and martin: will test
- phil: hoping to install on windows machine today
Power Mgt
-----------
- see email discussion separated into 2 threads:
https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-August/001048.html
https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-August/001077.html
- rob:
- general comment: need samples to show how to use
- 2 tgt audiences: current developers (creating tos components) and app developers
- lower level interfaces impose some of protocol targeted at kernel developers
- higher-level (svc scheduler - really liked idea from phil on poking component and
it might poke, stay up for a while)
- martin's proposal: might be overkill for level of abstraction and how it
impacts performance.
- dgay: can you really figure out a power level without talking to a sb which may
or may not be there. is it really just timers and interrupts? what about uart?
- rob: the uart component in 1.x there was no notion of power mgt; on or off; no
finer-grained mgt; suggesting that stuff in sched idle loop should perform
quickly and be able to determine power mode quickly; on mica2 implemented a little
broken ; pre-computed power state; individual components had to 'poke' state to
change it; tu-berlin msp430 do a quick scan of enabled sources of interrupts and
works fine; whether you enable uart interrupts still needs to be done by
components -- individula uart stack and exposed to rest of system & mged in
that context
- dgay: preference was for individual components to tell. push option that
recomputes the state;
- rob: another way of looking at address power units: power state is dirty
- dgay: don't have to like single component
- rob: doesn't necessarily break abstraction; cpus sleep basically managing;
makes sense to make bit of state
- phil: issues: if you go into a state that requires 5ms to wake timer wants
to know that; one thing to say "call out to everyone to figure it out" vs
"tell everyone what is happening"
- vlado: can combine 2 approaches; have 1us wakeups; timer says "i don't want
you to go lower than this possible level" and then you override what would
have been a default decision;
- phil: 4 people who care -> have to go with highest
- vlado: don't want it to be resolved
- dgay: unchanged and recompute
- phil: don't want to do this every time during an interrupt
- culler: when you would otherwise be idle
- culler: different point of view: ability to query each one doesn't have a
discipline for overall power mgt; not sure that start/stop in mica2 proposal
may not have been right; more important: here is pattern under which you write
components; not just on and off have to expose notion of costly transition; have
to write copmonnent in isolation
- dgay: talking about 3 different levels: rob system developer (start/stop seems
okay) , power component state (), 3rd one: users
- culler: one and two ; at level of user all of this is simpler; they don't want
to see it; historically very hard to get one that really worked in conventional
- phil: part of problem is multitasking system; lots of things going on
- culler: important leap because we can use a simplified appropach; nestfe: if
you shut down radio ;
- culler: how to write component so next level just works
- dgay: move on from microcontroller power space
- lama: talking about possibility of allowing apps to indicate what kind of
timeline they expect; was to think of an example from last week
example:
- you have different power modes; ability to trade off how fast you wake up
and have that app defined would be very good. Think of it as another component
even though it's not a peripheral.
- phil: is there a specific instance?
- dgay: think that might belong in a particular component for that sensor
- lama: but sensor writer doesn't know;
- dgay: i'm an app writer and I think that should clal the sensor driver
and the sensor driver indicates that.
- dgay: lowest level: microcontroller somehow figures out what state should
be in by polling components and can be overridden.
- phil: wakeup time for raise bar
- culler: idle loop is a max over some set of imputs;
- dgay: precomputed in some way
- phil: normal case cheap; override is special case
- rob: likes proposal; components can veto with latency preferences; might make
sense to expose that interface rather than exposing some notion of a pwr
state
- dgay: platform-specific or platform-independent
- rob: fancy sensor that has a particular requirement to react within a certain
time; would like platform independent way but imote2 reaction time might
be diff than mica2. what are the arguments being passed?
- david right: min over latencies
- dgay: don't know if that's always sufficient.
- phil: details will get you and won't be possible;
- dgay: start with platform-specific and if not specific can move on to
indepedent
- culler: latency: looks like a timer scheduler but you're scheuduling into
the future; under other proposal if you have a latency you have to adjust
into ?; will we replicate the structure needed to maintain timer schedule?
- dgay: someone needs to write up a tep
- vlado: remember mica2 -- went to queue of timers or was checking a register
so maybe we can do something like that using hw level timers where depend. on
latency in this loop what is min delay and dependent on that you choose what
state you go into; write of components should just register the latency by
defining some special timer that isn't really a timer but keeps track
of latencies
- dgay: may not address lama's concern though
- culler: if you want the result in some fixed time how do you get it?
- culler: asynchronous things that are predictable
- dgay: signal raises a pin and you know it's goint to happen in 3ms
- culler: inverse of split phase; looks as if nothing going on but I still
have to stay awake
- dgay: doesn't think we can just use timers; do need override (idea seemed
to be that the app has more info)
- dgay: higher level: are start/stop the right interface?
- vlado: start/stop and managing the power level
- culler: start/stop/pwr in earliest versions
- phil: at lowest level start/stop are ; with generics more simple to impose
policy
- dgay: do people disagree w/start/stop
- vlado: might need to be able to do some sort of ref counting; must register
with parent to
- phil: oski does this through a bitmap
- dgay: question: should oski be necessary for these system svcs to work? if 'no'
then these
- dgay: start/stop or stop/start/powerup/powerdown
- phil: want to think about it
- dgay: get issues on table
- rob: think he needs more than start/stop
- culler: is init different than start/stop
- dgay: yes, but maybe we call it
- culler: init is thing from start; host init start followed by powerup? or
can those 2 be formulated in init? or is there a stop that's so powerful
you have to init after use?
- vlado: many exs where you can't in radio stack cannot call cmd becuase you
can't giset pot to given value bec don't know if underlying system has
passed init
- dgay: isn't that a powerup op anyway? If you hadn't powered up radio would
you want to do that?
- vlado: if radio isn't on do you need to do that?
- dgay: is this something that you need to do before you power up? need
good example if we need to insert a layer beetween init/powerup
- culler: didn't nail init patter down carefully enough in 1.x; become clear
that you need to orches init seq; early on thought we could initialize some
things before others; certainly in nest stuff finding init process needs
to be carefully controlled; possibly separate discussions
- phil: hw init/ sw init ;
- culler: arguably phil says deicsion of init ordering is distributed thorughout
components;
- dgay: oculd be randon
- culler: problematic
- phil: could make it distributed by up-to-you; sw: yes it's distributed just
setting internal state and not claling anyone else
- culler: example: fan-in on init; historically some places overly flexible;
imagine that totally ordered linear sequence
- dgay: status auo : keep init as independent init; start happens after all; can
call substarts and can call commands on others after started; tempted to say
lets use this ; vlado: if you have example of post-init start
- vlado: will try to think about
- phil: maybe we want to think about other things: have start and stop how do
we specify power levels
- culler: want to get where we can state the invariants
- dgay: rob: strongly in favor of split/phase start/stop?
- phil: having only split phase requires tasks when not necessary;
- dgay: might want to address in tep
- dgay: operations when you call stop?
- phil: sys dependent
- phil: can choose to stop and cancel or stop when completed
- dgay: should
- phil: doint' get completion evenbt until you get the stop
- culler: do need to think through this a bit; implicit assumption: outstand
op can come to copletion bef we drop into low power state
- dgay: either wait until complete or cancel
- culler: command that says tell me when you have the next useful thing;
can't carry across a power down
- phil: radio complicated state machine; send packaet mac backoff
- culler: is stop iterative? can a comp continue trying to stop
iethe rcancel what doing or hang onto it; once i stop processing i'm
committed
- dgay: stop could return fail
- phil: then you're polling
- dgay: it's what david said
- phil: 1 packet: fine; send queue of 16 : do I stop
- dgay: policy of queue;
- phil: not going to get a completion event until you stop;
- culler: corresponding one: intelligent peripherals
- dgay: who's writing it?
- phil will do it; rob will be accessible by email ; back from germany on
the 7th; culler; lama; martin;
Other
-------
- dgay: gone for next 3 meetings; phil levis will run them. will check on
telecons;
-------------- next part --------------
_______________________________________________
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
More information about the Tinyos-host-mote-wg
mailing list