[Olsr-dev] ETX Calculation

[Markus Kittenberger]

how fast is your mobile node moving??
and what distance do the 2 nodes have (the one from which it should switch  
to the other)

what is "bigger" the goal of your testing?

--

a simple approach to play around, without needing to start coding right at  
the beginning

would be to use a small default lqmult on the mobile node (causing big ETX  
costs on the mobile node edges)
e.g. 0.50 (or maybe even 0.25)

this would mean a perfect link (formerly 1.00 would have costs of 2.0)
and a medium link with formerly 2.00 an etx of 4.00

the result is that the 2 hop route will be considered better, much  
earlier,.. (and as a positive side effect, your mobile node will be  
selected not so often for transit routes going over it,..)

further find out, if your problems are really only becauese of the  
mathematics of summing up etx-values without any further adaptions
or if its a problem of ETX "delay",..

so maybe, at the point where your mobile node already suffers too high  
packetloss
it should simply stop moving, and wait e.g. for a minute, while recording  
the ongoing changes of the lq values
(they will change as they are averaged)

if e.g. 15 seconds later lq reach a value that causes olsrd to switch to a  
longer (but better) route (as u desire)
then the problem is not really the metric, but the used averaging function

higher hello intervals might improve things (as the averaging has less  
effects,..)

but this usually you cant/want use dramatically higher hello intervals

it a next step it might be better to adapt the avaeraging and or the  
metric, (in the code )
but imho its better to evaluate what the problem is,..

regards Markus

p.s. etx is quite a old/simpe metric, which will not provide perfect  
routes for a single node, but does quite well for the whole network (at  
least if all nodes use same configuration *G (e.g same bitrate))


Am 18.03.2010, 20:54 Uhr, schrieb Vincent, Michael - 0665 - MITLL  
<(spam-protected)>:

> We're using OLSR (0.5.6-r7) in a testbed where a vehicle moves away from  
> a fixed point in a straight line.  As the signal weakens (LQ increases)  
> we add a relay node directly between the fixed point and moving vehicle  
> (on the straight line path).  The issue is that the ETX for the 2-hop  
> path (via the relay) doesn't register better than the direct path until  
> the packet loss on the direct path is way up.
>
>
> I've read the Link Quality README  
> (http://www.olsr.org/docs/README-Link-Quality.html) and it seems to  
> indicate that the ETX for a multi-hop path is the sum of the individual  
> paths (ETX1 + ETX2 ...).  Looking at the source code - this seems to be  
> the case also.
>
>
> We'd like to use the relay node quicker - that is, before the direct  
> path suffers from horrible packet loss and the ETX for the multi-hop  
> path takes over.  I think the summing of ETX without some 'scaling  
> factor' is the issue.
>
>
> I'm not a very skilled C programmer so my poking and tweaking the source  
> code hasn't yielded much I the way of a solution.  Any recommendations  
> on how to go about fixing this?
>
>
>     Cheers.
>


-- 
lg Markus