Thanks!
One thing that just came to my mind: when you used -o 3000 it takes very long to fill the sliding window size of OGM statistics. A sliding window size of 128 will take 384 seconds to fill up - more than 6 minutes! So if you just fire up the daemon and quickly start your measurements, the routing results can be quite arbitrary since there are not enough packets to make a reasonable decision.
But it might very well be the case that the broadcasts of the stretched link are propagating too far. In this case there is a workaround: You can increase the broadcast datarate if your wireless drivers/cards support this feature. This way you will decrease the range of OGM broadcasts. This has proven to be a good solution for mesh networks using OLSR at Freifunk.
Batman-0.2 still has some flaws in the routing metrics. The routing algorithm works nicely, but the metrics are sometimes unfortunate (choosing routes with bad performance in transmit direction, rumors saying it is preferring routes with small hopcount too much.) We are addressing this with 0.3 and in the experimental branch of batmand.
Also it could indicate a problem with the wireless devices.
cu elektra
2007/9/19, elektra onelektra@gmx.net:
Hi -
which version of batman are you using? And you should provide us with more
batman 0.2
details. Just saying Link is 'poor' or 'good' is very unprecise. Remember: A
direct route with 6 Megabit performs similar to a two-hop link with 12 Megabits on each link, since no retransmissions have to be made.
poor respectly to radio signal, A to C without B give 100kbit/s unstable
If you set the routes manually, it would be interesting to know the transfer
performance of the following:
A->C: 100kbit
A->B: full A->B->C: 1000kbit C->A: 100kbi C->B: 2500kbit C->B->A: 1000kbit
How many OGMs does A count directly from C and via B? (And vice versa) By the way: -o 3000 is quite slow for sending Originator messages if you have 20 nodes only. The default should be fine.
Ok, I removed -o 3000 and changed antenna in A node (less sensitive to node C). Now default route for A is B, that it is correct.
I am switching a 20 mesh node from olsrd but I have some problem in routing. I have no gateway node because I use openvpn to have a tunnel
with
PC. All nodes have: batman -g 0 -r 3 -o 3000 <interface>
node C has: batman -g 0 -r 3 -o 3000 -a 10.0.0.0/24 <interface>
I have several case like this:
A----good----B----good-----C-----10.0.0.0/24----PC ---------------poor-------------/
three node can communicate with all others but radio link from A to C is poor.
When node A want to communicate to node C it goes directly to C because batman calculate a direct route to it. But if I manually set routes to use node B connection from A to C is
good.
What is my mistake?
-r parameter in batmand daemon works only in searching gateway node?
...or
it works every time, also with normal node?