[net2-wg] 600 pps, high throughput

[Kyle Jamieson]

Phil's points are all well taken, but I'd hate to see this code not
make it into a distribution just because it's not useful to the
majority.  How about simply a flag that defaults to disabling CC2420 
DMA but allows the interested to enable it (and disable HF sampling)?
Or alternatively just including the code, but not wiring it up to 
anything?

Kyle

On Tue, Mar 14, 2006 at 09:35:33AM -0800, Philip Levis wrote:
> On Mar 13, 2006, at 10:02 PM, Joe Polastre wrote:
> 
> >This is so silly.  The only people using DMA in TinyOS are Moteiv,
> >Ben, August, and a bunch of mechanical engineers in Paul Wright's
> >group.  If you're using DMA, commit the code and let people use it.
> >If not, again, this is a moot and sily conversation.
> 
> OK, now we're venturing into the realm of OS design, so I'll be a bit  
> long winded.
> 
> Given that there are some people who use DMA, it would seem to me  
> that just committing a stack which would prevent them from doing so  
> is problematic: requiring Ben, August, Andrew, and others to rewrite  
> a CC2420 stack in order to perform high-frequency sampling seems like  
> a bad approach to me. Where's that going to leave them?
> 
> The tradeoff is this: the benefit of using DMA is that it reduces the  
> CPU cycles per packet and can (possibly) enable higher data-link  
> throughput. I'm not convinced that the former is a big deal, and the  
> latter has yet to be demonstrated. The cost of using DMA is that it  
> prevents applications from using one or two DMA channels, which might  
> preclude some applications.
> 
> The point about continuously sampling a sensor at a high rate  
> introducing a significant energy burden is correct, and well taken.  
> But the same could be said for network bandwidth: if you're concerned  
> with being able to maximize your throughput, you're implicitly  
> valuing performance over energy. E.g., for all of the demonstrations  
> of the bandwidth you can achieve when you turn off CSMA, I don't know  
> of reusable components that do so. Of course, you could always use  
> Arbiters to resolve contention for the DMA resource. This would  
> either introduce problematic jitter or require a policy where the  
> stack tries to acquire DMA but reverts to direct SPI (what Joe seemed  
> to be mentioning), increasing code size and complexity. Part of the  
> goal of 2.x is to *reduce* non-determinacy, for predictable and  
> robust operation, not increase it in the name of performance (think  
> Singularity, not Exokernel).
> 
> Part of the issue here might also be from the differing perspectives  
> created by different application intentions. E.g., the TMote Invent  
> demo app certainly has to do a lot of low-jitter I/O back and forth,  
> but so far TinyOS has been focused on embedded sensing, not a hand- 
> held user device. I'm sure the latter introduces a wholly different  
> set of tradeoffs, and I think that how they would influence TinyOS is  
> a very interesting question. However, unless we're going to decide  
> right now that being able to
> 
> In the end, besides being a cool demonstration of some of the  
> MSP430's capabilities, in the context of the CC2420 stack I just  
> don't understand what the compelling benefit is, and don't see how it  
> could outweigh the cost of precluding apps.
> 
> Phil
> 
> _______________________________________________
> net2-wg mailing list
> net2-wg at millennium.berkeley.edu
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/net2-wg