On Thu, Aug 28, 2008 at 1:06 AM, Michiel Konstapel <[EMAIL PROTECTED]> wrote: ... > > Our thinking was that instead of initializing the qualities and ETX to zero, > wouldn't it be better to set them "halfway"? That way, it is encoded that > the quality of the link is unknown, and could go either way. An initial > quality value of 180 (out of 255) means that 1/(inq*outq) results in an ETX > of 2; a 50% link.
Perhaps values other than 0 are better as initial values. Lets consider these CTP/LEEP mechanisms: 1. eetx for a link is not available until a link is mature 2. you transmit a lot of beacons in the beginning so there are enough beacons to bootstrap the values (are you using the router that uses Trickle timer to drive the beacons?) 3. you will eventually use the link that provides the best delivery performance So we are talking about initial setup time beyond link maturity? How much time? > Another observation of ours was that after a large number of beacons (> > MAX_PACKET_GAP) is missed, the route qualities are reset, but the ETX isn't. > In cases where a node that is a popular parent (say, the sink) is turned off > for a while, its children will see its ETX skyrocket as they try to get > packets through. When the node comes back online and starts sending beacons, > its old children will reset the link qualities to zero, but leave the ETX at > its inflated value. This means that it will take a very long time for the > node to send enough beacons to make itself look like a viable parent again. > Wouldn't it be better to reset the ETX at the same time as the in and out > qualities? Something like this: If you turn the node back on, you are right. But there are some other scenarios where what you propose might make things worse - lets say the link quality degrades and you slam the eetx value to the ceiling. Now, suddenly after more than MAX_PACKET_GAP (lets say after an hour), you receive a beacon, and BLQ_PKT_WINDOW consecutive beacons immediately after that. Is this link good or bad? If the last known etx for this link is a high value, why change it to some arbitrary value? One other detail - if you change inquality, you are changing the contribution to etx through the beacons. It is entirely possible that we are getting good etx estimate through the data packets while we are getting bad etx estimate through the beacons due to potentially different timescales at which the channel is sampled through these mechanisms. updateNeighborEntryIdx is only concerned with updating the beacon based estimate so it would not be appropriate to change eetx here because eetx also takes into account data pkt transmission statistics. > We've done some desktop experiments with INITIAL_QUALITY_ESTIMATE = 180 and > INITIAL_EETX_ESTIMATE = 10 and the recovery time improved greatly. However, > we don't have results for larger networks and were wondering if there might > be issues we haven't foreseen. I am not entirely convinced that we should optimize this link estimator to a scenario in which a link with a good track record suddenly becomes unavailable for a while and suddenly it becomes available with excellent delivery performance if that optimization is done at the expense of poorer response to other types of failure scenarios. Does your suggestion make recovery/adaptation worse for other types of failure scenarios? Overall, initialization value of these parameters become more important if you are using the link estimator without CTP. It would be good to see some numbers across the failure scenarios that you considered in your experiments. Thanks. - om_p _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
