[Tinyos-devel] message_t: starting to tease AM away from Serial and Radio

[Eric Decker]

On Wed, Jul 8, 2009 at 9:37 AM, Philip Levis <pal at cs.stanford.edu> wrote:

>
> On Jul 8, 2009, at 2:41 AM, Miklos Maroti wrote:
>
> 5) When faced by the choice of wasting at least 17 bytes for every
>> message_t or *occasionally* using a single memmove to reformat an <127
>> byte message, then I know that I am going to choose the latter.
>>
>
> The key point here is being able to bound the number of memmoves. E.g., if
> the design ensures that there will be at most one, that's a good tradeoff.
> If there can be a memmove for each layer in the stack, that's much less
> attractive.


I think we are in good shape.

It really is an issue of balancing the tradeoffs.

Depending on what kind of communications one is doing, one wants fewer or
more buffers allocated in the comm system.  One may or may not care some
number of wasted bytes (encap overhead).    But I think we always care about
bounding execution overhead.  So having the memmove if needed (at most one
is good) limited is a good thing.

The key to memmove style or overlapping encapsulations is having variable
encapsulations.  Once we go to variable encapsulations we get flexibility
and the ability to do cascading encapsulations as desired.  Flexibility.

The system I'm putting together will allow us to build different styles that
allow different tradeoffs to be optimized.

Back to Miklos' objections.  I think using variable encapsulations I think
we can build a system that allows him to mostly get rid of the 17 byte
overhead and do the memmove when he needs it.  That would be done in an
encapsulator.  This would be specified on a per platform/build basis so
could be tweaked for the desired tradeoffs.   By tweaking how much encap
overhead is at the front of the packet one can increase the likelihood that
cascading encapsulations will fit and not require a memmove.  This can be
specified by the developer when putting the application together.

As far as my overhead.  For a < 256 byte max payload (out the wire), I can
get my overhead down to 4 bytes per packet.  Seems reasonable to me.

how does that sound.  it is what I'm building and have mostly prototyped.

eric


Phil
>



-- 
Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering
UCSC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090708/3e59344b/attachment.htm