TTL yes, TTL no
Quoted 10 lines · Andrew Lunn
Quoted 4 lines
I think it is wrong: TQ is not decremented by
hop_penaltyeach time, but it is multiplied by (TQ_MAX-hop_penalty/TQ_MAX), then the number of hops is bigger than what you said. Withhop_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]
Quoted 2 lines
After 73 hops, TQ will be zero.
You are right, my raw calculus was too raw :p
Quoted 4 lines
Quoted 2 lines
Looking at the calculus above, I'm proposing to use TTL = ~135
TTL of 73 would be more accurate i think.
Yes.
Quoted 7 lines
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
Signature · 4 lines
Antonio Quartulli ..each of us alone is worth nothing.. Ernesto "Che" Guevara