Re: [B.A.T.M.A.N.] TTL yes, TTL no - B.A.T.M.A.N - lists.open-mesh.org

26 Mar 2011

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