[B.A.T.M.A.N.] batman network test bench

[B.A.T.M.A.N.] batman network test bench

[Marco Tozzini]

Hi All

I have 6 fonera stations (openwrt 8.09 + batman)
I would like to turn them on and check system stability and performance for some
time
Can you address me to a good way to test and log system performance/stability?

Thnaks
Marco

P.S.
I am available to help batman comunity with specific tests if any

Re: [B.A.T.M.A.N.] batman network test bench

[elektra]

Hi Marco!

You could introduce massive traffic from/to as many nodes as possible 
and keep them running for a long time. When I did so with Ubiquiti 
Nanostations I found that the CPU power was too low to saturate the 
network by downloading from /dev/zero from one node to /dev/null on 
another node. (I achieved only ~ 800 kByte/sec on a single hop link - 
rather than 3.3MByte/sec!) I have tried this with netcat, http, ftp, 
iperf. So I connected a laptop to the LAN port of the NS2 and downloaded 
from the laptop via the mesh into another laptop. Which seems to be 
highly impractical in your case.

Bear in mind that depending on the version of your Foneras you are 
rather going to learn about the instability of the hardware or drivers 
in ad-hoc mode. Earlier versions of the Fonera have hardware stability 
issues.

Recent versions of Kamikaze trunk seem to have stability issues in the 
Madwifi driver again - it seems like the stuck beacon problem is back, I 
have seen messages in dmesg that seem to indicate this :-(

Please check the uptime of the nodes during your tests - in case of a 
malfunction the watchdog will silently reboot. Which is what happened to 
me using a DIR-300 every one to three days.

For me I could fix the problem - I'm exclusively using mesh networking 
for all my IT communication needs 24/7 - why would I want to use 
wireless point-to-multipoint networking if I can have 
multipoint-to-multipoint wireless networking ;-)  - by switching to 
ahdemo mode. If you are not using ahdemo, make sure you use ad-hoc mode 
with the nosbeacon aka swmerge option.

That said I prefer testing in a productive environment - of course not 
all users are willing to bear a experimental network as their productive 
environment ;-) But if their connectivity doesn't work in the long run 
you as the admin will quickly get to know about it ;-)

Starting a little community mesh network is a great experiment on all 
kinds of levels, including the social non-OSI Layer 8! And you'll learn 
about technical problems you are never going to meet in your lab - 
because you'll see other drivers/devices in a heterogeneous environment 
trying to connect, introducing noise and trying to create IBSS-ID splits.

 From the protocol side we are keen on getting reports about the 
functionality and usability, CPU load, memory consumption, protocol 
overhead. However a mesh with 6 nodes is not pushing things to the limit 
for the Batman protocol (well, you can decrease the OGM interval to a 
much smaller value than 1 second!). But it will help developers to find 
bugs in recent code changes if you happen to test new versions.

Cheers,
Elektra



> I have 6 fonera stations (openwrt 8.09 + batman)
> I would like to turn them on and check system stability and performance for some
> time
> Can you address me to a good way to test and log system performance/stability?
>
> Thnaks
> Marco
>
> P.S.
> I am available to help batman comunity with specific tests if any.
>   

Re: [B.A.T.M.A.N.] batman network test bench

[marco tozzini]

Hi Elektra

Thank you for your great support
Now I have 4 station on and connected through batman

Following your tips I did setup a netcat data exchange

I had very few time to work on this project, so my main task till now  
was to turn on and connect the more station I can
In the next days I would like to check if they are still there (without 
watchdog reboot in the meantime) and are still transferring data

I hope I can achieve a serious test bench in the near future - I will be 
back with better news

Thanks
Cheers
Marco
 

elektra wrote:
> Hi Marco!
>
> You could introduce massive traffic from/to as many nodes as possible 
> and keep them running for a long time. When I did so with Ubiquiti 
> Nanostations I found that the CPU power was too low to saturate the 
> network by downloading from /dev/zero from one node to /dev/null on 
> another node. (I achieved only ~ 800 kByte/sec on a single hop link - 
> rather than 3.3MByte/sec!) I have tried this with netcat, http, ftp, 
> iperf. So I connected a laptop to the LAN port of the NS2 and 
> downloaded from the laptop via the mesh into another laptop. Which 
> seems to be highly impractical in your case.
>
> Bear in mind that depending on the version of your Foneras you are 
> rather going to learn about the instability of the hardware or drivers 
> in ad-hoc mode. Earlier versions of the Fonera have hardware stability 
> issues.
>
> Recent versions of Kamikaze trunk seem to have stability issues in the 
> Madwifi driver again - it seems like the stuck beacon problem is back, 
> I have seen messages in dmesg that seem to indicate this :-(
>
> Please check the uptime of the nodes during your tests - in case of a 
> malfunction the watchdog will silently reboot. Which is what happened 
> to me using a DIR-300 every one to three days.
>
> For me I could fix the problem - I'm exclusively using mesh networking 
> for all my IT communication needs 24/7 - why would I want to use 
> wireless point-to-multipoint networking if I can have 
> multipoint-to-multipoint wireless networking ;-)  - by switching to 
> ahdemo mode. If you are not using ahdemo, make sure you use ad-hoc 
> mode with the nosbeacon aka swmerge option.
>
> That said I prefer testing in a productive environment - of course not 
> all users are willing to bear a experimental network as their 
> productive environment ;-) But if their connectivity doesn't work in 
> the long run you as the admin will quickly get to know about it ;-)
>
> Starting a little community mesh network is a great experiment on all 
> kinds of levels, including the social non-OSI Layer 8! And you'll 
> learn about technical problems you are never going to meet in your lab 
> - because you'll see other drivers/devices in a heterogeneous 
> environment trying to connect, introducing noise and trying to create 
> IBSS-ID splits.
>
> From the protocol side we are keen on getting reports about the 
> functionality and usability, CPU load, memory consumption, protocol 
> overhead. However a mesh with 6 nodes is not pushing things to the 
> limit for the Batman protocol (well, you can decrease the OGM interval 
> to a much smaller value than 1 second!). But it will help developers 
> to find bugs in recent code changes if you happen to test new versions.
>
> Cheers,
> Elektra
>