From: Sven Eckelmann <sven@narfation.org>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] Routing decisions
Date: Thu, 5 May 2011 19:35:11 +0200 [thread overview]
Message-ID: <201105051935.12979.sven@narfation.org> (raw)
In-Reply-To: <BANLkTin0ge+SNpLr3wjTibT303PZ8SRbGw@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1720 bytes --]
Ed Okerson wrote:
> On Thu, May 5, 2011 at 10:44 AM, Marek Lindner <lindner_marek@yahoo.de>
wrote:
> > Hi,
> >
> >> We are evaluating using Batman in an environment where there could be
> >> 200-300 devices in a single building. We started out setting up 10
> >> devices in our office to figure out how everything works and do some
> >> throughput testing. We have noticed that the routing decisions always
> >> send the packet to the node towards the destination with the highest
> >> signal strength. This causes the packet to always traverse the
> >> network with the maximum possible number of hops, which causes
> >> performance to degrade quickly. Is it possible to use a different
> >> routing algorithm? It would seem that sending to the node closest to
> >> the destination that the source node can still communicate with
> >> directly would minimize the number of hops.
> >
> > if you wish to minimize the number of hops you have to increase the hop
> > penalty. Check the "hop penalty" section here:
> > http://www.open-mesh.org/wiki/batman-adv/Tweaking
>
> That seems to indicate that it is a per node setting, i.e. "using this
> node will incur a penalty of x". That is also not the desired
> behavior. For our installation all nodes are in a fixed location, so
> using a particular node as a next hop in the route may incur a penalty
> for one source node, but not another. This should be dynamically
> determined for each route from each source to each destination to
> minimize hops.
So you have to increase the hop penalty everywhere to force the routing
algorithm to reduce the number of hops and prefer worse routes with less hops.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2011-05-05 17:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-05 15:37 [B.A.T.M.A.N.] Routing decisions Ed Okerson
2011-05-05 15:44 ` Marek Lindner
2011-05-05 17:25 ` Ed Okerson
2011-05-05 17:35 ` Sven Eckelmann [this message]
[not found] ` <BANLkTikO=kA3JVfACWmnyV3QhDksGhQL8Q@mail.gmail.com>
2011-05-05 18:26 ` Sven Eckelmann
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=201105051935.12979.sven@narfation.org \
--to=sven@narfation.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