[net2-wg] 600 pps, high throughput

[Philip Levis]

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