20 Mar
2009
20 Mar
'09
9:15 p.m.
This is my typical view, of my batman fonera stations, from my batman
laptop (with atheros wifi pcmcia)
Originator (#/255) Nexthop [outgoingIF]: Potential nexthops
... [B.A.T.M.A.N. 0.3, MainIF/IP: wlan1/192.168.2.65, UT: 0d 0h36m]
192.168.2.200 (245) 192.168.2.200 [ wlan1]: 192.168.2.200
(245) 192.168.2.203 (211) 192.168.2.201 (244)
192.168.2.201 (253) 192.168.2.201 [ wlan1]: 192.168.2.201
(253) 192.168.2.200 (234) 192.168.2.203 (209)
192.168.2.203 (233) 192.168.2.200 [ wlan1]: 192.168.2.203
(231) 192.168.2.200 (233) 192.168.2.201 (231)
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
I don't think it's normal, isn't it?
Ciao
Marco
21 Mar
21 Mar
1:17 a.m.
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
7:49 a.m.
Marek Lindner wrote:
On Saturday 21 March 2009 05:15:14 marco tozzini
wrote:
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
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
7:58 a.m.
Marco
can you post the 802.11 and inet configurations of the involved iface
(I think wlan1) and a memory usage hwile batmand is running?
Antonio
On Sat, March 21, 2009 8:49, marco tozzini said:
Marek Lindner wrote:
On Saturday 21 March 2009 05:15:14 marco tozzini
wrote:
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
_______________________________________________
B.A.T.M.A.N mailing list
B.A.T.M.A.N(a)open-mesh.net
https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
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
8:34 a.m.
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
8:53 a.m.
* Marek Lindner <lindner_marek(a)yahoo.de> [21.03.2009 09:45]:
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). :-)
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)
important question:
are batman-adv-packets transfered in multicast-rate?
greets,
Bastian Bittorf
23 Mar
23 Mar
4:55 p.m.
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
25 Mar
25 Mar
9:40 p.m.
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
;)
Ciao
Marco
10:17 p.m.
On Mar 25, 2009, at 10:40 PM, marco tozzini wrote:
marco tozzini wrote:
which proves that batman finds better routes ;-))))
LOL, sorry could not resist :)
(joke!)
you obviously have a different problem here than routing protocols.
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
5177
days inactive
5182
days old
b.a.t.m.a.n@lists.open-mesh.org
8 comments
5 participants
participants (5)
-
Antonio Anselmi -
Bastian Bittorf -
L. Aaron Kaplan -
marco tozzini -
Marek Lindner