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
next prev parent 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