Re: [B.A.T.M.A.N.] Change metric and priorize links with the best Bandwidth

["Nicolás Echániz" <nicoechaniz@codigosur.org>]

On 08/13/2012 08:18 PM, Esteban Municio wrote:
> Hi all
> 
> I'm asking myself if should be possible change the actual metric(TQ)
> in batman-adv or if there is a tool to configurte it.
> 
> We are deploying a rural mesh network where the nodes generally will
> be static in the same place, but maybe the links beetwen the nodes
> will have a unnestable bandwidth.
> 
> So we are looking for what protocol (with any plugin) is more
> efficient for our network.
> 
> Batman-adv have TQ like metric, but we would like that the nodes route
> the traffic priorizing the links with best bandwith available instead
> the links with best QoS. That is because finally, all the links tend
> to have ETX=1 at the expense of reduce de bandwidth(reducing the
> modulation and codification scheme in order to reduce looses), so the
> nodes route always for the shortest path...
> 
> Is there any solution for this?Do you recommend us change to another
> mesh protocol(OLSR+plugin) or another "static" protocol(ej: OSPF)? It
> is possible configurate batman-adv to get the fastest route instead
> the safer?
> Or maybe I am not understanding something...Am I proposing a fool thing?

At QuintanaLibre we experimented quite a bit with this and came to the
conclusion that setting a high multicast rate is a good solution to
"force" batman to only use good (in terms of bandwidth) links.

If you set the mcast_rate high, for example (OpenWRT):

config 'wifi-iface'
	option 'device' 'radio0'
	option 'mcast_rate' '54000'

then low bandwidth routes will effectively become invisible to batman.

We are using this setup in a semi-rural network, 3.5Km wide with 15
active nodes (as of today) and it works very well.

By doing this you loose redundancy, so if you have a node with only one
high bandwidth link and that link fails, the node won't have other
routes to use. In our experience this is OK because the alternative
low-bandwidth routes that are available if mcast_rate is very low are
not of much real use.


Cheers,
NicoEchániz