On Sat, Mar 26, 2011 at 06:45:48PM +0100, Andrew Lunn wrote:

...

I think it is wrong: TQ is not decremented by hop_penalty each time, but it is multiplied by (TQ_MAX-hop_penalty/TQ_MAX), then the number of hops is bigger than what you said. With hop_penalty = 10 we can probably reach ~135 hops (raw calculus 255*(TQ_MAX-hop_penalty/TQ_MAX)^135) =~ 0)

I agree with the principle. However, you need to take rounding into effect. The kernel does integer arithmetic and TQ is always an integer value. I also got it wrong in my last post. I used the wrong round function when calculating the values. Using rounddown() i get:

[cut]

After 73 hops, TQ will be zero.

You are right, my raw calculus was too raw :p

...

Looking at the calculus above, I'm proposing to use TTL = ~135

TTL of 73 would be more accurate i think.

Yes.

Which leads me to a new question. At WBM we talked about moving the HNAs out of the OGMs. If we had a really big mesh, with more than 73 hops from side to side, do we get into a situation where we have HNAs from more than 73 hops away, but no idea how to route to them since OGMs got dropped when TQ reached 0?

Mh..The HNA request is triggered by the TTVN carried into the OGM. Then a node far more than 73 hops should never ask for HNAs it cannot reach.. Moreover, a route toward a client is never allocated if we don't have its orig_node in our DB.

Bye