[Battlemesh] Battlemesh v5 tests
neumann at cgws.de
Tue Mar 13 12:51:46 CET 2012
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
>> 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
>> 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
>> 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
>> 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
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... :)
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
More information about the Battlemesh