[Battlemesh] Battlemesh v5 tests

Clauz clauz at ninux.org
Mon Mar 5 17:16:00 CET 2012


On 03/01/2012 01:37 PM, Juliusz Chroboczek wrote:
>> So, here are some ideas:
>> http://www.battlemesh.org/BattleMeshV5/Tests
> Excellent. Thanks a lot for your work, Clauz.
> In the "Channel Surfer" test, I'd like to see throughput results (not
> necessarily taken into account in the competition, just for my own
> education).

I think we can easily measure that.

> I'm not sure it's possible -- but if we have the hardware, I'd like to
> see a test with multi-radio nodes.

I don't know if we have multi-radio, so the tests are designed for
single-radio devices.

Babel(z) is AFAIK the only protocol (of the battlemesh) designed to be
radio/channel-aware, so I wonder what other protocol developers think
about this test, and if they think that a protocol not designed to be
radio-aware can however choose the best path...

> 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.

> Finally, are you planning to run all routing protocols in parallel, or
> sequentially?

Sequentially as much as possible... That is: I think is not feasible to
reboot the whole network with a new configuration at each protocol
change, so we can have different overlay networks with different address
spaces, each associated to a routing protocol (as usual), but run tests
on one address space at a time.

> Thanks again,

Thank you for the feedback!


More information about the Battlemesh mailing list