On 03/31/2012 06:03 PM, dan wrote:
On Sat, Mar 31, 2012 at 12:11 PM, Guido Iribarren guidoiribarren@buenosaireslibre.org wrote:
On Sat, Mar 31, 2012 at 12:45 PM, Dan Denson dandenson@gmail.com wrote:
I think I understand. Basically, so long as two interfaces both have a path the to destination of acceptable quality, it will send the packets out the interface that did not receive the packets. Hop count doesn't have a direct effect, we don't really care about hop count, only about link quality.
Is that the case?
If hop count doesn't really matter, how do I identify my high quality, high capacity backhauls?
In batworld, by their high TQ (= AFAIU lack of packet loss to destination.) no capacity involved in the calculations.
(but devs might correct me if i'm being too shortsighted!)
according to the docs, capacity is not used in the calculation. It is assumed that lowest TQ is always the best route. Hop count adds a default '10' to the TQ which is adjustable. I figure this means that I can give a supernode a lower hop cost than the default 10 which should slide the TQ in favor of using this node as the optimal path.
I also infer that this means that picostations running batman-adv that are part of the supernode 'cluster' are going to also add a hop penalty to the TQ. From what I can tell though, link aggregation only cares if a interaces/links have an acceptable TQ, not an equal TQ, though I suspect that two picos in a supernode config would end up providing the same hop count and similar TQ anyway, assuming solid wireless links.
it's a tricky task to try and convince batman-adv to favour certain routes.
Our strategy in QuintanaLibre has been to lower the hop penalty but also to increase multicast rate where necessary.
This effectively "invisibilizes" some links for batman.
You should use this with care, mainly if you are playing with it remotely because you may be left out of a portion of your network.
We have reduced hop_penalty to zero on certain "preferred" nodes and also increased mcast_rate where necessary.
Your mcast_rate can actually be heterogeneous across the network.
For example, we have an Ubiquiti BulletM2 with a 14db panel antenna which is "seen" even by the furthest node, which establishes a low rate link that has low throughput but looses very few packets, so batman "thinks" it's actually a good route when in practice it's not.
So we set the Bullet mcast_rate high like so:
config 'wifi-iface' option 'device' 'radio0' option 'mcast_rate' '54000' ...
and then only those nodes than can establish a really good link to the Bullet will see it as a valid route while others will ignore it.
It took a lot of time to find out this subtleties and we don't even know if this is the "canonical" method but it does work very well to discard undesired low rate routes.
In your setup, I think you could increase hop penalty for your picostations, lower the hop penalty for your supernodes and also set their mcast_rate high, so that picostations won't choose to route directly to a far supernode but rather send traffic to their nearest supernode which will have a solid route to the next one... that is if I correctly understood what you are trying to accomplish.
Please share your findings on these matters, as we may all profit from each other's experimentation work!
Cheers, NicoEchániz