[Tinyos-devel] [Tinyos-help] Collection: Loosing Connection to a Node

[Philip Levis]

On Apr 28, 2008, at 9:25 AM, Bulut ERSAVAS wrote:
> Hi Phil & Omprakash,
>
> It appears that the LPL is to blame for the misbehavior of CTP in  
> our case. As Omprakash suggested, I repeated the tests by turning  
> off the LPL. Nodes quickly discovered routes and packet losses were  
> reduced dramatically.
>
> We later on retried with LPL but reduced our LPL sleep interval from  
> 1000 ms to 125 ms. Attached you can find the logs. Node 7 is again  
> TelosB with debug logs. The performance is much better, however, is  
> not as sharp as it would be with no LPL. I would suspect that the  
> beacons or the acks are getting lost when the LPL is activated,  
> hence the poor route discovery process and the large amount of data  
> loss.
>
> When LPL is used, are the beacons timed for the LPL sleep interval?  
> For instance, we use setRxSleepInterval to set the receiving node's  
> sleep interval for data transmission. Is something similar done for  
> CTP beacons?
>
> Also, when CTP is used, ETX values are quite large. Even for a  
> single hop, it is about 265. You will notice ETX values as large as  
> 700 with 3-hop routes. However, with no LPL it was usually less than  
> 300 even for 6-hop routes. Can this be due to beacons/acks getting  
> lost with LPL?
>
> In summary, attached logs (4BITLE & LPL w/ 125ms interval) are much  
> better than the ones I sent last week (LE | 4BITLE & LPL w/ 1000ms  
> interval). But still, for an acceptable power consumption level, we  
> need to use 1000ms or larger sleep interval. So, in this case, is it  
> possible to improve CTP to better work with LPL? How can we assist  
> you in this process?

It might be useful to move this discussion over to -devel.

The first step for doing this was to reduce CTP's control traffic so  
that it can function well with LPL (early versions had high control  
load). We completed this work a few weeks ago, and Om has just checked  
the changes into CVS.

Now that CTP has a low control load, the next step is starting testing  
with LPL and figuring out what's going wrong and why. From your  
traces, it looks like LPL has a low packet delivery success rate. We  
should start talking with David Moss (the LPL author) to figure out  
what's going on. The most useful thing you can do is take debug traces  
of your networks and parse them. Om has a set of tools for plotting  
results from traces; he can share them with you. They produce HTML  
pages like this:

http://enl.usc.edu/~om_p/net2/ctp4bitle/expt-01172008-1/

Phil