Marek Lindner wrote:

On Saturday 21 March 2009 05:15:14 marco tozzini wrote:

...

and this is the results 192.168.2.200 : xmt/rcv/%loss = 1000/928/7%, min/avg/max = 1.23/2.04/92.8 192.168.2.201 : xmt/rcv/%loss = 1000/759/24%, min/avg/max = 1.28/3.11/27.5 192.168.2.203 : xmt/rcv/%loss = 1000/766/23%, min/avg/max = 1.33/3.36/38.7

I don't think it's normal, isn't it?

What exactly are you referring to ? Are you wondering why the packet loss of fping is higher than predicted by batman ?

Regards, Marek

Hi Merek From batman debug output it seems batman station has a good view one to each other, but working on this systems is very annoying: ssh terminal has a wobbling response to commands

Is this the behavior I shall expect from a good working mesh system?

Ciao Marco

On Saturday 21 March 2009 15:49:46 marco tozzini wrote:

From batman debug output it seems batman station has a good view one to each other, but working on this systems is very annoying: ssh terminal has a wobbling response to commands

Is this the behavior I shall expect from a good working mesh system?

Please keep in mind what batman is doing to obtain these results: It broadcasts packets and receives broadcasts. From that it tries to give an estimation about the networks status and the link conditions. Obviously, you can't derive latency or bandwidth throughput from this information base.

Lets look at your fping test: Usually batman broadcasts are sent once a second. While rebroadcasting a jitter is applied to reduce the probability of collisions with other batman packets. When you run fping on 192.168.2.200/30 you will generate traffic that has a high probability of collisions which will lead to different test results.

If you compare test mechanisms make sure they run under the same conditions otherwise it does not make sense to draw conclusions from it. The batman TQ value tells you how batman sees the link at this specific time - nothing more or less. This is an approximation of the reality. If you have ideas how to improve it let us know. Meanwhile, we can try to help getting your wifi up to speed (see antonios mail). :-)

Regards, Marek

On Saturday 21 March 2009 16:53:36 Bastian Bittorf wrote:

in OLSR networks we change the multicast-rate, to allow only links with "reasonable" bandwith to be used. Maybe this is also a good idea for batman. In a dense network, set you multicast-rate to 12mbit on all nodes, in a "normal" network you can use e.g. 5.5 mbit. (this helps the routing daemon and does nearly not change the normal network behavior)

Basically I agree here. Setting the transfer rate helps stabilizing the network. Not so sure why you say "in OLSR networks" as this is more a wifi setting rather than a mesh protocol thing. Is that integrated into OLSR ?

important question: are batman-adv-packets transfered in multicast-rate?

batman-adv-packets are ethernet broadcast packets and follow the same broadcast mechanisms as IP broadcasts.

Regards, Marek

On Mar 25, 2009, at 10:40 PM, marco tozzini wrote:

marco tozzini wrote:

...

from my laptop fping -c 1000 -g 192.168.2.200/30

and this is the results 192.168.2.200 : xmt/rcv/%loss = 1000/928/7%, min/avg/max = 1.23/2.04/92.8 192.168.2.201 : xmt/rcv/%loss = 1000/759/24%, min/avg/max = 1.28/3.11/27.5 192.168.2.203 : xmt/rcv/%loss = 1000/766/23%, min/avg/max = 1.33/3.36/38.7

Just for completeness ... here it is (almost) the same test with OLSRd

192.168.2.200 : xmt/rcv/%loss = 1000/902/9%, min/avg/max = 1.27/2.39/35.3 192.168.2.201 : xmt/rcv/%loss = 1000/815/18%, min/avg/max = 1.28/3.80/73.6 192.168.2.203 : xmt/rcv/%loss = 1000/821/17%, min/avg/max = 1.31/3.56/122

which proves that batman finds better routes ;-))))

LOL, sorry could not resist :) (joke!)

you obviously have a different problem here than routing protocols.