On Fri, Jan 27, 2012 at 11:54:25PM +0800, Marek Lindner wrote: > > Hi Andrew, > > > Do you have any performance analysis to show this is really helpful > > and not harmful? > > > > I've seen indoor results where i had to reduce the hop penalty, > > otherwise BATMAN was taking a short path which worked badly. By > > reducing the hop penalty, so encouraging it to take more hops, i got > > usable routes. > > > > I see the danger here this could break working networks, so maybe it > > needs justification? > > as a matter of fact I do believe it is helpful. In various networks (more > than > a dozen) I have seen that batman would largely favor multi-hop routes, thus > reducing the overall throughput. By setting it to a higher value I regained > some of its performance. The networks are still up & running - I can show > them > to you if you are interested.
I have seen similar results in my test setups. One simple scenario where I have
seen route flapping with hop penalty 10 in multiple setups is: If some nodes are
at the same place (e.g. a few netbooks on the same table), they often don't use
the direct route but change to a two-hop route to reach their destination - even
if the direct link is nearly perfect. There don't even has to be payload traffic
involved, the routes just flap because of the little tq oscillations from some
packets lost.
In these tests, I have also changed the hop penalty to 30 (or even 50,
sometimes)
and these problems are gone.
The TQ metric has limited informative value in terms of available
bandwidth/chosen
rate. The default wifi broadcast/multicast rate of 1 Mbit/s may lead to
prefering
low-rate 1 hop links over high-rate 2 hop links. However, this can be often
fixed
by increasing the mcast rate (mac80211 or madwifi support this). We should
consider
including rate information in future metrics.
Anyway, for now and our current TQ metric I strongly agree in increasing the hop
penalty too.
Cheers,
Simon
>
> So, you had to reduce the default value of 10 to something even smaller ? A
> hop penalty of 10 results in a penatly of 4% per hop. A rough equivalent of 2
> lost packets (62/64). Does not sound very much to me. Can you explain your
> test setup a little more ?
>
> Nevertheless, this patch was intended to get a discussion going. The main
> problem I have been seeing in the last weeks is that OGM broadcasts have a
> hard time estimating the link quality / throughput on 11n devices. I'll also
> try to hack a proof of concept for an rssi influence on the routing and see
> if
> that has a better effect.
signature.asc
Description: Digital signature
