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
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara