[Tinyos-host-mote-wg] [Tinyos-2.0wg] Re: [Tinyos-2-commits] CVS: tinyos-2.x/tos/chips/cc2420 CC2420Command.nc, NONE, 1.1.2.1 CC2420ControlP.nc, NONE, 1.1.2.1 CC2420RadioP.nc, NONE, 1.1.2.1 CC2420Ram.nc, NONE, 1.1.2.1 CC2420ActiveMessageC.nc, 1.1.2.1, 1.1.2.2 CC2420ActiveMessageP.nc, 1.1

[Philip Levis]

On Mon, 2005-09-12 at 11:46 -0700, Joe Polastre wrote:
> >   3) Adjusted backoff timers for greater throughput and fairness.
> >      The 1.x stack had the congestion timer be 4x the initial
> >      backoff timer: this creates a capture effect, where a node
> >      who just transmitted is more likely to be able to transmit
> >      again. I observed this behavior with my slamming test app: one
> >      node would transmit a lot, then the other node would transmit
> >      a lot. I reversed the relationship and cut the timers in half:
> >      initial is now 32us-1ms and congestion is 32us-256us. Now, with
> >      two nodes slamming each other, I observe 330-340 pps in each
> >      direction, and the tx/rx counts are within 3-4% of each other
> >      (reasonable fairness). Given that CCA is being done with
> >      a timer in the micaZ, I suspect that Telos throughput would
> >      be higher.
> 
> The original stack was as per the 802.15.4 backoff timer specification.
> 

>From what I can tell, the 802.15.4 specification involves exponential
backoff, but I don't see that in the 1.x code (the default values are
constants). Of course, this is likely to lead to the capture problem.
Looks like there should be two configuration options, 802.15.4 compliant
and fair.


> >   5) Added another platform component, CC2420PlatformAlarmC, which
> >      represents the async timer the platform must supply for the
> >      TX backoff/abort logic.
> 
> This can be handled with the Timer system, there is no longer a need
> for a CC2420 Alarm but rather just an Alarm<T32khz>
> 

Yes, on the interface level (it's using Alarm<T32kHz>. The issue is that
Alarms are part of the HAL, so you need a component to present a
platform/chip independent alarm.


> 
> We had this debate back in April 04.  Basically the split phase makes
> it impossible to deal with from a logic perspective.

I think that the command marshaling approach could make it possible. A
lot of it comes down to the granularity at which you acquire the bus. I
plan on starting with fine grained acquisition and then maybe exploring
finer grained access.

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