[Tinyos-devel] CTP with -20dbm on Mirage

Omprakash Gnawali gnawali at usc.edu
Thu Dec 27 16:24:59 PST 2007


Here are the results from the experiments that Rodrigo did on Mirage:
http://enl.usc.edu/~om_p/net2/ctp4bitle/mirage-12242007/figures.html

He used tx power of 5.

Besides the values of the metrics, one thing that is different from
previous set of Mirage experiments is higher variation in results.

It seem a few nodes are almost disconnected but they are not - you
need to look at goodcost(t) as well as delivery ratio distribution.
They are able to deliver packets with higher alphas just fine.

I added  a new graph called goodcost-depth ratio which is the 4th
graph from the top of the page. The goodcost-depth ratio has
definitely increased with tx power of 5. This means the paths are
worse - it could be because there are no better paths or ctp does not
find better paths. What are these bad nodes? We can look at two places
- there is a graph called "Delivery ratio by node id". Looking at that
graph, many times the nodes that offer low delivery ratio with a5 are
different from the nodes that offer low delivery ratio with a6.
Looking at cumgoodcost(t), node 140 stands out. It is easy to see the
trend in goodcost using this node. It will be good to get a physical
explanation for why node 140 is special.

I looked at the some detailed time series, what caught my eye was what
node 62 was doing in a6 experiment (a6 subdirectory). WAIT line for
140 is higher than that for rest of the nodes because 140 offered the
smallest delivery ratio. What is interesting is 62's WAIT line starts
around 2500 and climbs at a rapid pace - all the pkts are failing. It
turns out 62 acquires a new parent for the first time around 2500, and
it picks bad parent - node 71 and 40. Here is a list of time, nodes,
and etx on the beacon pkts sent by 62:

time nodeid etx
2481.109 71 311
2502.773 71 311
2536.99 71 311
2612.957 71 311
2781.141 71 311
3075.032 71 311
3255.311 40 277
3277.852 40 277
3320.793 40 277
3413.087 40 277
3621.512 40 277
3981.549 40 277
4581.116 40 291

It turns out 71 and 40 offer low delivery ratios as well. I don't know
how unique this scenario is but there might be a bug somewhere that
prevents the etx from increasing even though all the pkts from node 62
are failing. Not a single packet arrive at the sink from 62.

- om_p


More information about the Tinyos-devel mailing list