public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
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
Date: Tue, 15 Nov 2011 00:43:13 +0100	[thread overview]
Message-ID: <20111114234312.GA28724@ritirata.org> (raw)
In-Reply-To: <4EC171B2.9070605@inti.gob.ar>

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

  reply	other threads:[~2011-11-14 23:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.5.1321268402.29081.b.a.t.m.a.n@lists.open-mesh.org>
2011-11-14 19:53 ` [B.A.T.M.A.N.] Problem to find better Route gtolon
2011-11-14 23:43   ` Antonio Quartulli [this message]
2011-11-15  1:40   ` Marek Lindner
     [not found] <mailman.3.1321354802.20324.b.a.t.m.a.n@lists.open-mesh.org>
2011-11-15 17:59 ` gtolon
2011-11-16  3:30   ` Marek Lindner
2011-11-16  8:32     ` Antonio Quartulli
2011-11-16  8:49       ` Marek Lindner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111114234312.GA28724@ritirata.org \
    --to=ordex@autistici.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox