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.] any throughput mechanism or plans?
Date: Sat, 31 Mar 2012 23:43:23 +0300 [thread overview]
Message-ID: <20120331204322.GA31423@ritirata.org> (raw)
In-Reply-To: <CAA_JP8UrWSzLYoUEhrzbT1fjeedp28B0dr7dMB_TizLkr+4RNg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
On Sat, Mar 31, 2012 at 04:22:06 -0600, dan wrote:
> I can't see anything in my reading on this.
>
> Is there a mechanism to identify throughput between two nodes? or
> between a client and a destination for the purpose of routing through
> the highest throughput path?
>
> For instance, track the maximum throughput on each interface over
> time. Compare it to the current throughput on the interface and send
> what is leftover as 'available throughput' with the TQ each node. Now
> instead of adding up the numbers as with TQ, just take the min. Take
> the lowest throughput along the path and have a node be able to
> utilize the highest throughput path that has acceptable TQ. As a
> node's interface gets loaded up (vs observed maximum) it will inform
> it's neighbors in the same way it informs them of the TQ of each
> interface and then the neighbors can choose to route around if there
> is a good alternate path.
>
> Basically, I'm thinking that TQ isn't the only or most optimal way to
> route simply because available throughput should be considered
> somehow. As far as I can tell, a 56k link with .001% packet loss is
> better than a 54Mb link with .1% packet loss, though both are solid
> interfaces and the 54Mb link should be prefered heavily over the 56k
> link. The 56k link probably will start dropping packets once it is
> saturated, but one client might run up against slow ACKs keeping the
> remote server from sending enough data to saturate the connection so
> the client could be getting a very slow connection while a 54Mb link
> sits virtually unused.
Hello Dan,
there is not such mechanism in batman-adv right now. It is a really good idea
and we already started to think about that during WBMv5. Personally, I'm
applying to the GSOC2012 and I'm proposing something similar.
I also think that packet loss is not the correct way to go.
Regarding your idea, how would you measure the maximum throughput?
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2012-03-31 20:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-31 22:22 [B.A.T.M.A.N.] any throughput mechanism or plans? dan
2012-03-31 20:43 ` Antonio Quartulli [this message]
2012-04-01 2:02 ` dan
2012-04-01 2:39 ` Guido Iribarren
2012-04-01 2:53 ` Guido Iribarren
2012-04-01 2:53 ` Dan Denson
2012-04-01 21:35 ` Marek Lindner
2012-04-01 21:32 ` Marek Lindner
2012-04-01 22:23 ` dan
2012-04-02 9:32 ` Marek Lindner
2012-04-02 13:35 ` dan
2012-04-02 15:29 ` Marek Lindner
2012-04-02 18:21 ` dan
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=20120331204322.GA31423@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.