Thank you very much for your kind reply,
I think, I'm on the wrong train with my assumptions.
However, I can not spot my mistake on my own.
Please help me understand.
If more than MAX_PKT_GAP beacons are lost, the code will reinitialize
the link information. The code is in the same file.
If I understand it correctly, this would require at least one
additional beacon from node 1 to be received by node 2, after node 1
has already failed. Because this code is executed, if a beacon is
received with a sequencenumber (MAX_PKT_GAP + lastseq).
But in this scenario no more beacons can sent by node 1.
Is there any other condition to reset the link costs? Maybe a timestamp
based, that resets entries of the NeighborTable, if no beacons
have been received from that neighbour for a certain time?
But first you should convince yourself that beacons will not kick in
and drive the link cost up for the scenario you are thinking.
Yes. That is my assumption. As node 1 gets down, no more beacons can be
received from it. But node 2 will continue sending packets to its next
hop (node 1). And data based estimates will increase the costs of the
link between node 2 and 1.
Thanks in advance
Christian
On Sun, 18 Sep 2011 01:38:44 -0500
Omprakash Gnawali gnaw...@cs.stanford.edu wrote:
On Fri, Sep 9, 2011 at 11:57 AM, Christian christ...@wwad.de wrote:
Dear TinyOS community,
I have a problem understanding, how CTP's updateRouteTask() works,
if the 4-Bit Link Estimator is used.
Consider the following example:
Node 2 with costs 70 is currently using node 1 (costs 20) as parent.
He could also choose node 3, that has costs 60 over a link of costs
10.
(1:20)
^
|
|50
|
(2:70) --- (3:60)
10
If I understand it correctly, when node 1 gets down, the costs of
the link to node 1 will reach the maximum value of DLQ_PKT_WINDOW *
10 = 50 (LinkEstimatorP.nc l. 296 in updateDETX()), because no acks
can be received from node 1 as well as no beacons, that could
update beacon based link etx.
The problem, that I see here, is, that the link's costs cannot get
worse than 50 (limited by DLQ_PKT_WINDOW) and that updateRouteTask()
would not change to node 3, because the path over node 3 is not
significantly (PARENT_SWITCH_THRESHOLD) better than the path over
node 1.
So it will stay with node 1 as parent even if node 1 isn't available
anymore.
Please explain: is this really the case or what do I miss out?
If more than MAX_PKT_GAP beacons are lost, the code will reinitialize
the link information. The code is in the same file.
Just in case I'm right, one could solve this problem by requiring
every parent's link costs to be below DLQ_PKT_WINDOW*10 and
changing to another node in updateRouteTask(), if this is not the
case.
But first you should convince yourself that beacons will not kick in
and drive the link cost up for the scenario you are thinking.
If you notice improvement in experiments, I am happy to consider
changes. Let me know.
- om_p
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
