Re: [B.A.T.M.A.N.] Problem to find better Route

Re: [B.A.T.M.A.N.] Problem to find better Route

[gtolon]

Thank you for your answers. I copy the Originator's tables for the three 
nodes:

A)   (MAC: b2:48:7a:c8:a2:65)

root@OpenWrt:/# batctl o
[B.A.T.M.A.N. adv 2011.2.0, MainIF/MAC: wlan1/b2:48:7a:c8:a2:65 (bat0)]
   Originator      last-seen (#/255)           Nexthop [outgoingIF]:   
Potential nexthops ...
16:d6:4d:3a:3c:3c     0.790s   (213) 16:d6:4d:3a:3c:3c  [     wlan1]: 
16:d6:4d:3a:3d:d8 (193) 16:d6:4d:3a:3c:3c  (213)
16:d6:4d:3a:3d:d8    0.810s   (255) 16:d6:4d:3a:3d:d8 [     wlan1]: 
16:d6:4d:3a:3c:3c  (190) 16:d6:4d:3a:3d:d8 (255)

B)   (MAC: 16:d6:4d:3a:3c:3c)

root@OpenWrt:/# batctl o
[B.A.T.M.A.N. adv 2011.2.0, MainIF/MAC: wlan1/16:d6:4d:3a:3c:3c (bat0)]
   Originator      last-seen (#/255)           Nexthop [outgoingIF]:   
Potential nexthops ...
b2:48:7a:c8:a2:65     0.840s   (235) b2:48:7a:c8:a2:65 [     wlan1]: 
16:d6:4d:3a:3d:d8 (236) b2:48:7a:c8:a2:65 (235)
16:d6:4d:3a:3d:d8    0.640s   (253) 16:d6:4d:3a:3d:d8 [     wlan1]: 
b2:48:7a:c8:a2:65 (205) 16:d6:4d:3a:3d:d8 (253)

C)   (MAC:  16:d6:4d:3a:3d:d8)

root@OpenWrt:/# batctl o
[B.A.T.M.A.N. adv 2011.2.0, MainIF/MAC: wlan1/16:d6:4d:3a:3d:d8 (bat0)]
   Originator      last-seen (#/255)           Nexthop [outgoingIF]:   
Potential nexthops ...
16:d6:4d:3a:3c:3c    0.060s   (208) 16:d6:4d:3a:3c:3c [     wlan1]: 
b2:48:7a:c8:a2:65 (182) 16:d6:4d:3a:3c:3c (208)
b2:48:7a:c8:a2:65    0.090s   (234) b2:48:7a:c8:a2:65 [     wlan1]: 
16:d6:4d:3a:3c:3c (182) b2:48:7a:c8:a2:65 (234)

This is a typical state of the tables. We tryed setting the hop pennalty 
parameter to 1, but the behaviour hasn't changed.

> ------------------------------
>
> Message: 4
> Date: Tue, 15 Nov 2011 00:43:13 +0100
> From: Antonio Quartulli<ordex@autistici.org>
> To: The list for a Better Approach To Mobile Ad-hoc Networking
> 	<b.a.t.m.a.n@lists.open-mesh.org>
> Subject: Re: [B.A.T.M.A.N.] Problem to find better Route
> Message-ID:<20111114234312.GA28724@ritirata.org>
> Content-Type: text/plain; charset=utf-8
>
> Hello Gabriel,
>
> On Mon, Nov 14, 2011 at 04:53:22 -0300,gtolon@inti.gob.ar  wrote:
>> >  Hi. We are using batman-adv 2011.2.0 with Openwrt Backfire-rc6 on D-Link
>> >  routers, and we're making some tests with iperf to measure bitrate
>> >  capabilities between nodes. When we put three nodes aligned we notice
>> >  that the obtained bitrate between the extreme nodes strongly depends on
>> >  the batman path between them. To make it clear, we have:
>> >  
>> >  A ---------- B ---------- C
>> >  
>> >  With a dinstance of about 20 meters between A and B, and the same
>> >  distance between B and C. The problem is that sometimes, A and C get
>> >  connected directly in terms of batman-adv protocol (checked with batctl
>> >  o), and when that happens, the bitrates are very poor (less than 1Mbps),
>> >  like if B wasn't there. In fact we disconnected B and obtained very
>> >  similar results.
>> >  
>> >  Then we reduced tx power settings on A and C, forcing the B hop between
>> >  them, and we got much better speeds (~20Mbps). We've read about ELP and
>> >  think that maybe simple OGM messages are not good to measure link
>> >  quility between A and C in this example, could that be the problem? In
>> >  that case is there a way to fix this with actual batman-adv algorithms?
>> >  Thanks in advance!
>> >  
>> >  Gabriel
>> >  
> I think other people will give you better answer than this one, but just as
> start: OGM are sent in broadcast, which by definition uses a low rate that
> implies "better transmission than higher rates".
> Therefore a link having an high TQ doesn't necessarily has a good quality at
> "high rates" (as you are experiencing).
>
> In my opinion the problem resides in the fact that batman-adv uses broadcast
> packets to measure link qualities which leads to the aforementioned problem.
>
> I don't know if ELP would help in this sense because as far as I know it still
> uses broadcast packets.
>
> Please guys correct me if I am wrong.
>
>
> Cheers,
>
>
>
> -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto 
> "Che" Guevara ------------------------------ Message: 5 Date: Tue, 15 
> Nov 2011 09:40:36 +0800 From: Marek Lindner <lindner_marek@yahoo.de> 
> To: "The list for a Better Approach To Mobile Ad-hoc Networking" 
> <b.a.t.m.a.n@lists.open-mesh.org> Subject: Re: [B.A.T.M.A.N.] Problem 
> to find better Route Message-ID: 
> <201111150940.36605.lindner_marek@yahoo.de> Content-Type: Text/Plain; 
> charset="iso-8859-1" Hi,
>> >  With a dinstance of about 20 meters between A and B, and the same
>> >  distance between B and C. The problem is that sometimes, A and C get
>> >  connected directly in terms of batman-adv protocol (checked with batctl
>> >  o), and when that happens, the bitrates are very poor (less than 1Mbps),
>> >  like if B wasn't there. In fact we disconnected B and obtained very
>> >  similar results.
> would you mind sharing the orignator tables of the involved nodes ?
>
>
>> >  Then we reduced tx power settings on A and C, forcing the B hop between
>> >  them, and we got much better speeds (~20Mbps). We've read about ELP and
>> >  think that maybe simple OGM messages are not good to measure link
>> >  quility between A and C in this example, could that be the problem? In
>> >  that case is there a way to fix this with actual batman-adv algorithms?
> You can play with the hop penalty parameter to encourage batman to use fewer
> or more hops (depending on your needs).
>
> Regards,
> Marek
>
>
> ------------------------------

Re: [B.A.T.M.A.N.] Problem to find better Route

[Marek Lindner]

On Wednesday, November 16, 2011 01:59:11 gtolon@inti.gob.ar wrote:
> Thank you for your answers. I copy the Originator's tables for the three
> nodes:
> 
> [..]
>
> This is a typical state of the tables. We tryed setting the hop pennalty
> parameter to 1, but the behaviour hasn't changed.

The TQ values are quite close, so I can imagine that batman has a hard time 
finding the better path. You could try to set the broadcast rate to a fixed 
value (5.5 or even 18) to force the driver to not send the broadcasts at such 
a low rate.

Cheers,
Marek

Re: [B.A.T.M.A.N.] Problem to find better Route

[Antonio Quartulli]

On Wed, Nov 16, 2011 at 11:30:05 +0800, Marek Lindner wrote:
> The TQ values are quite close, so I can imagine that batman has a hard time 
> finding the better path. You could try to set the broadcast rate to a fixed 
> value (5.5 or even 18) to force the driver to not send the broadcasts at such 
> a low rate.

Can you really do that?


Cheers,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

Re: [B.A.T.M.A.N.] Problem to find better Route

[Marek Lindner]

On Wednesday, November 16, 2011 16:32:11 Antonio Quartulli wrote:
> On Wed, Nov 16, 2011 at 11:30:05 +0800, Marek Lindner wrote:
> > The TQ values are quite close, so I can imagine that batman has a hard
> > time finding the better path. You could try to set the broadcast rate to
> > a fixed value (5.5 or even 18) to force the driver to not send the
> > broadcasts at such a low rate.
> 
> Can you really do that?

Yap. If you want to find out how: google is your friend.  :-)

Cheers,
Marek

[B.A.T.M.A.N.] Problem to find better Route

[gtolon]

Hi. We are using batman-adv 2011.2.0 with Openwrt Backfire-rc6 on D-Link 
routers, and we're making some tests with iperf to measure bitrate 
capabilities between nodes. When we put three nodes aligned we notice 
that the obtained bitrate between the extreme nodes strongly depends on 
the batman path between them. To make it clear, we have:

A ---------- B ---------- C

With a dinstance of about 20 meters between A and B, and the same 
distance between B and C. The problem is that sometimes, A and C get 
connected directly in terms of batman-adv protocol (checked with batctl 
o), and when that happens, the bitrates are very poor (less than 1Mbps), 
like if B wasn't there. In fact we disconnected B and obtained very 
similar results.

Then we reduced tx power settings on A and C, forcing the B hop between 
them, and we got much better speeds (~20Mbps). We've read about ELP and 
think that maybe simple OGM messages are not good to measure link 
quility between A and C in this example, could that be the problem? In 
that case is there a way to fix this with actual batman-adv algorithms? 
Thanks in advance!

Gabriel


El 14/11/2011 08:00 a.m., b.a.t.m.a.n-request@lists.open-mesh.org escribió:
> Send B.A.T.M.A.N mailing list submissions to
> 	b.a.t.m.a.n@lists.open-mesh.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n
> or, via email, send a message with subject or body 'help' to
> 	b.a.t.m.a.n-request@lists.open-mesh.org
>
> You can reach the person managing the list at
> 	b.a.t.m.a.n-owner@lists.open-mesh.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of B.A.T.M.A.N digest..."
>
>
> Today's Topics:
>
>     1. Re: [PATCH] add make install (Sven Eckelmann)
>     2. Re: [PATCH] add make install (Sven Eckelmann)
>     3. Re: [PATCH] add make install (Alexey Fisher)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 14 Nov 2011 11:21:12 +0100
> From: Sven Eckelmann<sven@narfation.org>
> To: b.a.t.m.a.n@lists.open-mesh.org
> Cc: lindner_marek@yahoo.de
> Subject: Re: [B.A.T.M.A.N.] [PATCH] add make install
> Message-ID:<1428522.agqKBYpyMC@sven-laptop.home.narfation.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Monday 14 November 2011 10:38:07 Sven Eckelmann wrote:
>> On Monday 14 November 2011 10:11:32 Alexey Fisher wrote:
>>> Signed-off-by: Alexey Fisher<bug-track@fisher-privat.net>
>>> ---
>>>
>>>   Makefile |    3 +++
>>>   1 files changed, 3 insertions(+), 0 deletions(-)
> [...]
>> NAck: Sven Eckelmann<sven@narfation.org>
> And also "Nack" for not updating the README [1]
>
> Kind regards,
> 	Sven
>
> [1] http://www.open-mesh.org/wiki/open-mesh/Contribute#Submitting-patches
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 836 bytes
> Desc: This is a digitally signed message part.
> URL:<http://lists.open-mesh.org/pipermail/b.a.t.m.a.n/attachments/20111114/850391c0/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 14 Nov 2011 11:29:36 +0100
> From: Sven Eckelmann<sven@narfation.org>
> To: Alexey Fisher<bug-track@fisher-privat.net>
> Cc: b.a.t.m.a.n@lists.open-mesh.org, lindner_marek@yahoo.de
> Subject: Re: [B.A.T.M.A.N.] [PATCH] add make install
> Message-ID:<1956205.mQFSXpQuIf@sven-laptop.home.narfation.org>
> Content-Type: text/plain; charset="utf-8"
>
> On Monday 14 November 2011 11:19:19 Alexey Fisher wrote:
> [...]
>> Thank you,
>> so you will send your patch? I prefer last version, to make testing easier.
> I personally don't care. Feel free to fix your patch and send a new version
> (but think about adding the ":" after "install" -- the character magically
> disappeared when I wrote the mail).
>
> And don't forget the documentation part as it is always hard to remember
> everything on the day the release is made, but easy when you just made the
> patch. :)
>
> Thanks,
> 	Sven
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 836 bytes
> Desc: This is a digitally signed message part.
> URL:<http://lists.open-mesh.org/pipermail/b.a.t.m.a.n/attachments/20111114/329c477e/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 14 Nov 2011 11:37:55 +0100
> From: Alexey Fisher<bug-track@fisher-privat.net>
> To: Sven Eckelmann<sven@narfation.org>
> Cc: b.a.t.m.a.n@lists.open-mesh.org, lindner_marek@yahoo.de
> Subject: Re: [B.A.T.M.A.N.] [PATCH] add make install
> Message-ID:<4EC0EF83.2060602@fisher-privat.net>
> Content-Type: text/plain; charset="utf-8"
>
> On 14.11.2011 11:29, Sven Eckelmann wrote:
>> On Monday 14 November 2011 11:19:19 Alexey Fisher wrote:
>> [...]
>>> Thank you,
>>> so you will send your patch? I prefer last version, to make testing easier.
>> I personally don't care. Feel free to fix your patch and send a new version
>> (but think about adding the ":" after "install" -- the character magically
>> disappeared when I wrote the mail).
>>
>> And don't forget the documentation part as it is always hard to remember
>> everything on the day the release is made, but easy when you just made the
>> patch. :)
> Corrected.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-add-make-install-option.patch
> Type: text/x-patch
> Size: 959 bytes
> Desc: not available
> URL:<http://lists.open-mesh.org/pipermail/b.a.t.m.a.n/attachments/20111114/969101dd/attachment-0001.bin>
>
> ------------------------------
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@lists.open-mesh.org
> https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n
>
>
> End of B.A.T.M.A.N Digest, Vol 59, Issue 19
> *******************************************
>

Re: [B.A.T.M.A.N.] Problem to find better Route

[Antonio Quartulli]

Hello Gabriel,

On Mon, Nov 14, 2011 at 04:53:22 -0300, gtolon@inti.gob.ar wrote:
> Hi. We are using batman-adv 2011.2.0 with Openwrt Backfire-rc6 on D-Link 
> routers, and we're making some tests with iperf to measure bitrate 
> capabilities between nodes. When we put three nodes aligned we notice 
> that the obtained bitrate between the extreme nodes strongly depends on 
> the batman path between them. To make it clear, we have:
> 
> A ---------- B ---------- C
> 
> With a dinstance of about 20 meters between A and B, and the same 
> distance between B and C. The problem is that sometimes, A and C get 
> connected directly in terms of batman-adv protocol (checked with batctl 
> o), and when that happens, the bitrates are very poor (less than 1Mbps), 
> like if B wasn't there. In fact we disconnected B and obtained very 
> similar results.
> 
> Then we reduced tx power settings on A and C, forcing the B hop between 
> them, and we got much better speeds (~20Mbps). We've read about ELP and 
> think that maybe simple OGM messages are not good to measure link 
> quility between A and C in this example, could that be the problem? In 
> that case is there a way to fix this with actual batman-adv algorithms? 
> Thanks in advance!
> 
> Gabriel
> 

I think other people will give you better answer than this one, but just as
start: OGM are sent in broadcast, which by definition uses a low rate that
implies "better transmission than higher rates".
Therefore a link having an high TQ doesn't necessarily has a good quality at
"high rates" (as you are experiencing).

In my opinion the problem resides in the fact that batman-adv uses broadcast
packets to measure link qualities which leads to the aforementioned problem.

I don't know if ELP would help in this sense because as far as I know it still
uses broadcast packets.

Please guys correct me if I am wrong.


Cheers,



-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

Re: [B.A.T.M.A.N.] Problem to find better Route

[Marek Lindner]

Hi,

> With a dinstance of about 20 meters between A and B, and the same 
> distance between B and C. The problem is that sometimes, A and C get 
> connected directly in terms of batman-adv protocol (checked with batctl 
> o), and when that happens, the bitrates are very poor (less than 1Mbps), 
> like if B wasn't there. In fact we disconnected B and obtained very 
> similar results.

would you mind sharing the orignator tables of the involved nodes ?


> Then we reduced tx power settings on A and C, forcing the B hop between 
> them, and we got much better speeds (~20Mbps). We've read about ELP and 
> think that maybe simple OGM messages are not good to measure link 
> quility between A and C in this example, could that be the problem? In 
> that case is there a way to fix this with actual batman-adv algorithms? 

You can play with the hop penalty parameter to encourage batman to use fewer 
or more hops (depending on your needs).

Regards,
Marek