BATMAN IV in batman-advanced uses TQ_GLOBAL_WINDOW_SIZE of 10.
When a packet is received, the TQ value transmitted in the packet will
be weighted and stored. The sliding window of neighbours who did not
forward an OGM with this sequence number will have this entry set to zero.
The old neighbours' sliding window will be filled with zeros, while
the new neighbours' sliding window will gain more and more (weighted)
TQ values. Once the Average of the sliding window is higher than the
old one, the route will switch.
So it should change after maximum of 10 seconds. The new neighbour will
start off with bad tq values for the TQ: Neighbours have not answered a
lot of OGMs, so the asymetric penalty reduces the stored TQ value a lot.
This is probably the reason why it does not switch in 5 seconds, but
takes a bit longer.
If you want to read in the source code, look into isBidirectionalNeigh()
and update_orig(). This is the theory, i don't guarantee for bugs. ;)
On Wed, Jul 30, 2008 at 05:09:56PM +0200, cipollone wrote:
I'm studying how BATMAN Advanced-Kernel work.
I'm interesting in knowing what is the behavior of BATMAN and the
reaction time of the protocol if a node exit from a range node and
entered in another range node. I have discovered that (in a simulation
with 3 hosts with a mobile node and 2 static node) BATMAN find a new
route losing more or less 8 seconds, passing from one to the other node.
But the OGMs time is 1 s and the sliding window is 64, so why it can
lost 64 seconds to find another route (or 32)?
So there is a equation to define a the time lost to find a new route?
I have an originator interval of 1 seconds (set by default).
B.A.T.M.A.N mailing list