[Battlemesh] Battlemesh v5 tests

[Axel Neumann]

On 11.03.2012 12:40, Clauz wrote:
> 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?

likely.

>   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
My experience is that its not ignored (with madwifi or ath5/9k.
But the effect often does not match your expectations :-(


If I remember right, during last events the txpower (if not on all then 
at least on many devices)
was already configured to a very low value because we wanted to avoid 
that every node sees
every other node.



>> If this is not possible, what about turning them down for 5 minutes?
> This is realistic, and feasible... :)

sounds good.

cu
/axel

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