[Battlemesh] Battlemesh v5 tests

Axel Neumann neumann at cgws.de
Thu Mar 8 10:20:54 CET 2012


On 06.03.2012 15:24, Clauz wrote:
> On 03/06/2012 01:09 PM, Juliusz Chroboczek wrote:
>>>> In the "Convergence Time" test, you need to clarify what you mean by
>>>> "turn off" -- that could mean switching the radio on/off, restarting the
>>>> routing daemon, or rebooting the node.  (All of our routing protocols
>>>> keep state across a link outage, and Babel keeps state between daemon
>>>> restarts -- a Babel node that has lost its persistent state can take up
>>>> to three minutes to reinsert itself into the mesh.)
>>> What I have in mind is powering off (and then back on) the node.
>> Babel nodes that lose their seqno may take up to 200 seconds to rejoin
>> the network; hence this test doesn't make much sense for Babel.

Bmx6 would suffer from a similar problem. It incorporates a duplicate 
address detection mechanism
which would falsely assume for 100 seconds that there is a second node 
announcing the
same address as the node that was turned down.

Keep this in mind when reading my following comments :-)

>> Once again, I have no objection if you penalise Babel for that in the
>> competition, but I'd be grateful if you could run a test that makes
>> sense for Babel in addition to the standardised test.  I suggest either
>> ifdown/ifup of the radio interface, or shutting down and restarting the
>> babeld daemon cleanly (so that /var/lib/babel-state is preserved).
> The test tries to mimic what happens in real community networks, where
> complete hardware reboots (due to power outages, people just plugging
> everything out of the socket and back in when things don't work, etc.)
> are much more common than interface or daemon restarts...



In my experience there are two main reasons for relevant changes in the 
topology
of wireless mesh networks (significantly changing link qualities or 
links even going
up or down):

1)  changing radio environments

This could be for example the microwave oven started by the neighbor
or the hundrets of wifi surfers that sleep during night but get active 
in the morning,
or maybe (less common) because a mobile node moves to a new location.

At least from several roof-top mesh nodes I know that they tend to have
uptimes of several month but are exposed to significantly changing 
interference
conditions and successive route changes several times per day.


2)  intuitively deactivated and reactivated nodes to save power.

Power outages are rather seldom. Especially short-time ones.
But what happens is that nodes are turned down intuitively to save power 
(yes,
people living in trailerparks and having solar energy as their only 
power source still
have such kind of problems). Or to be moved to a new location.
But in either case, when nodes are turned down intuitively, they usually 
remain down
for more than 10 minutes.


Therefore I would actually vote for something like decreasing tx-power,
turn off the interface, or temporary unplug the ethernet cable (if its 
about
alternating the link-quality of an ethernet link.


If this is not possible, what about turning them down for 5 minutes?

@ Juliusz
Would that bypass the 200sec seqno recovery issue of Babel nodes?


greetings,
/axel





> The tests were thought with a "real community network problems" point of
> view in mind. If we want to move to a "protocol-fair" point of view,
> then I will definitely have to rethink most of them! :)

> bye,
> Clauz
>
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
>




More information about the Battlemesh mailing list