[Battlemesh] Battlemesh v5 tests

[Clauz]

On 03/08/2012 09:20 AM, Axel Neumann wrote:
> 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.


I don't like turning off the interface, because is not realistic at all.
But yes, changing radio environment is everyday matter. I have two
questions (for everybody):
 1. do you think we can set up a topology in which a txpower change can
trigger a route change? We will be needing directional antennas, right?
 2. do you think decreasing the tx power via software will work well on
our hardware? My experience is that most drivers tend to ignore this setting


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

This is realistic, and feasible... :)

Clauz