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
