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.