[Tinyos-host-mote-wg] [Tinyos-2.0wg] 09/14/2005 Telecon Notes

[Kristin Wright]

-------------- next part --------------

Notes from 09/14/2005 TinyOS 2.0 Working Group 

Phil Buonnadonna (Arched Rock), David Culler (Arched Rock),
Ben Greenstein (UCLA), Phil Levis (Stanford), Lama Nachman (Intel)
Rob Szewczyk (Moteiv), Kristin Wright (Arched Rock)

09/21/2005 Agenda
------------------
- Status
- TEP113 Serial Communication (possibly deferred)
- Power Management, cont'd

09/14/2005 Action Items
------------------------
- philb, lama, rob & phil: TEP112 by Monday or so
- all: Please read TEP113 

09/14/2005 Discussion Notes
----------------------------------------------------------

Status
--------
- CC2420:
 - Phil: CC2420 now conforms with TEP108 (Resource Arbitration); uses
   immediate request interface and fails if can't get the bus; next step:
   move from synchronous to split-phase; measured overhead of resource
   interface: 6-7%; could be either lost packets or processing overhead
Serial stack: 
  - Phil: TEP113 committed; please read and talk about next week
NSDI: 
 - Phil: set up a CVS server, not too late to be involved if you're interested

Power Management
-----------------
culler: 
- after rereading TEPS and underlying code, pwr mgt might warrant a critique pass 
  on the code 
- example: ADC TEP; describes general interface; msp implements a second model; Atmel implements
  a third; inside msp there are upcalls on every getdata to get the configuration which are passed large
  structures; msp makes timer assumptions (regarding whether timers are required or not required
  for repeated samplings) that the atmel doesn't make; not clear in ADC: what are the higher-level
  usage models supported; do the pieces go together? 
- Power is going one of several items that ties all the pieces together; Ex: power, storage stack 
  says it will take care of power; not clear that rob's GDI work is the right thing to do; 
  pieces fit together better than they do right now. 
Phil: 
- inconsistencies come from fact that ADCs originally could have an HIL but TEP has changed; 
  keep in mind that TEPs are in draft status 
culler: 
- ok to have TEPs be simpler but have them explain more about how pieces fit 
  together than where we are today; another example: radio vs bus (business of bus between what interfaces); 
  couldn't make heads or tails of it (tep 104) 
phil: 
- those were initial ideas, not touched for a year, ex: the notion of bus arbitration 
  completely supplanted by 108

Power Management
-----------------
- Latency Override 
- rob: somewhat convinced that a general purpose latency interface may
  be too complex, but don't know what would replace it; at a loss as
  to how to communcate pm req't down to controller so that it can
  choose sleep mode; always platform specific (lives at HPL level);
  then we have to build high-level policies?
- lama: have multiple power modes; can tradeoff pwr / wakeup latency;
  sensorboard that is waking up mote, would be nice to specify what
  latency is expected from the app's perspective. can't really use
  timer settings to determine.
- rob: do you envision state? 
- lama: no state -> reset of processor 
- rob: how do you envionsion app communicating to rest of system? call
  command that specifies latency?
- lama: originates from backend; from app or sb, still have to
  determine latency required; phil was suggesting that you make it
  visible to sensorboard and then the sensorboard takes care of it; but
  how do you make the sensorboard
- phil: how about there's an override -- a command which uses fanout
  resolution of overriders -- determines the max of the low-power state;
  in normal case, it's a no-op (go to deepest sleep); latency: need to
  wake in 5ms so can't go to deep; on top of that, can have components
  that specify latency - on imote2 can't go below powerStateX. 2 layers:
  one layer interacts with scheduler; other layer interacts with app.
- ben: decouples speicification of power state with what hardware can
  actually do; gives example of 5ms vs 5.1ms; another way: "prefer
  deep sleep" and have it return the latency involved; suggest a query
  operation to return the platform's mappings to the power modes or have
  some compile-time facility
- philb: it seems as if we're trying to engineer for hard real-time 
  deadline; not clear that the rest of tos2 is built for; similar to
  rearranging deck chairs on the titanic
- phil: tasks don't, but you do expect interrupts to run reasonably soon; 
  but time constants are much larger (5ms) and that's part of the concern.
- philb: it seems arbitrary
- rob: middle component addresses to a large extent
- rob: the other thing we're talking about is what is the interrupt
  latency; all this discussion only applies to interrupts; should't have
  tasks that turn off interrupts for many ms
- phil: john regehr has looked at ways to enforce, but his software 
  hasn't gone to prime-time
- rob: feel that we have gone through a number of times; maybe we
  should just write the tep and send for comments;
- phil: take martin's tep, modify & add, present to group
- philb, lama, rob & phil: to do tep modification
- philb: what is the entity that initiates a change in the power state? 
  Fully-automatic or whatever app component? 
- rob: Scheduler maintains the processor power state subject to these
  exceptions that are flagged by the individual components through the
  change-of-state mechanism they have internally
- rob: app has no say on processor power state; individual components 
  (radio stack) manage radio,etc.
- benn: requesting QoS, but not exactly 
- phil: routing layer could break; could have no parent because the node 
  powered down and the parent link was not determined (or the parent down)
- philb: the routing layer is broken if it can't deal with suspend/resume; 
  analogy: laptop / IP layer -- expect IP to resume working after the 
  laptop suspends
- philb: worry about one component deciding not to turn off the node
  and then the nodes always stay awake; have *always* gotten into
  trouble with this; greatly hinders debugging
- phil: agree -- bunch of components were written without pwr mgt in mind;
  component turns off unless you periodically kick it awake (policy
  level)
- lama: see where philb is coming from; you can debug the rest of your
life -- having a complete override is a nice thing to have; most app
writers have had some wayward components

Next week
----------
- Useful version of tep112 by Monday or so
- Please read tep113, might defer discussion until later




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