[Tinyos-devel] RE: 2.0.2 CC2420

[David Moss]

I don't think it's crucial.  I verified the changes work with the version of
the stack I just committed to the repository.  We're just not sure how it
scales in larger networks.

One thing I can say is the ack wait period was increased before this change
from 128 to 256 [us].  Can't remember when that change was made or if it was
a result of problems Matt Welsh's group was having or what, but it should
improve ack reliability over earlier versions.

The latest version in CVS right now is a working and tested version of what
I sent Mike yesterday.

-David


-----Original Message-----
From: J. Ryan Stinnett [mailto:jryans at rice.edu] 
Sent: Friday, July 06, 2007 11:54 AM
To: David Moss
Cc: Philip Levis; 'Chieh-Jan (Mike) Liang';
tinyos-devel at millennium.berkeley.edu
Subject: Re: 2.0.2 CC2420

Quoting Philip Levis <pal at cs.stanford.edu>:
>
> On Jul 5, 2007, at 11:18 AM, David Moss wrote:
>
> >
> >> I don't mind doing the characterization, since after all I'm one
> >> of the
> >> people pushing for the change.  I've got a small 10 mote test bed
> >> currently on idle, if that seems like it would suffice.  Any
> >> suggestions
> >> on specs or stats?
> >
> > Phil had access to acknowledgement stats before.  Phil - do you have
> > suggestions on how this should proceed?
> > -David
> >
> >
>
> This is the link to Jung Il's study:
>
> http://sing.stanford.edu:8081/JungilChoi/FWP/FWP_packet_acknowledgements
>
> Please note that it was for a modified version of the MAC, and so the
> timing values (TX rate) may differ from the standard TinyOS ones.
>
> Jung Il can provide greater details, but essentially he compared the
> ACK success rate and transmit rate to using his SACKs and using the
> standard AUTOACKs in Jonathan Hui's original stack. He measured
> different payload lengths due to the effect they have on the SACK
> latency sensitivity. If you read the whole packet before SACKing,
> then long packets hurt you; if you only read the header before
> SACKing, then short packets hurt you. These results were for his
> approach of SACKing after the destination address.
>
> Phil
>
>

Should I do a comparison between the current stack and the modified
CC2420ReceiveP that David attached in his reply to Mike, or should I wait
for
the 2.0.2 version?  This leads me to another question: did you want to see
these results before 2.0.2 goes out or is that not crucial?

- Ryan