public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
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.] any throughput mechanism or plans?
Date: Mon, 2 Apr 2012 11:32:42 +0200	[thread overview]
Message-ID: <201204021132.42284.lindner_marek@yahoo.de> (raw)
In-Reply-To: <CAA_JP8VhdK__mRZoL6DY+vPth9wOE6=BqLE5EDpV5rC0RB2kCQ@mail.gmail.com>

On Monday, April 02, 2012 00:23:36 dan wrote:
> I am making some assumptions.  I assume that the link will at some
> point become saturated.  If we simply track the maximum then we can
> advertise an available amount.

This will result in a metric optimizing paths for the highest throughput ever 
recorded. In reality one can easily observe many links with variable 
throughput. Sometimes you get a spike of high throughput although the average 
speed is lower. Or your wifi environment changes with a negative impact on the 
throughput.
 

> How do we identify this? Well, if the C radio has historically
> transfered 10Mb (on the interface closest to the gateway) and we have
> tracked it, we can take the current 5Mb away from that an see that
> there is 5Mb remaining.  This does also assume that a specific
> interface has a consistent speed.

That is not a safe assumption.


> I don't suggest making throughput the #1 route selection method, only
> what would be used if similar quality links where available.  in this
> case, A<>B and A<>F are very similar quality so we would use
> available throughput in the decision making.  Have a tunable threshold
> for TQ vs TQ before this load balancing is taken into account.

Interesting idea. Have to think about this a little bit.


> I have another though on how to determine maximum speed but it is more
> 'destructive'
> Have batman-adv do a test on each link for tx, rx, and bi-directional
> and store the results and consider these the interfaces potential.
> Also identify if an interface is FD or HD.  retest on an interval,
> and/or when the TQ on a link is consistently worse than when tested
> last.  If the test was thorough enough, it would be able to identify
> at what throughput ping times and packet loss spike and have an
> effective 'safe' maximum vs absolute maximum.

Yes, we still have the "costly" way of detecting the link throughput 
ourselves. What do you think about the idea of asking the wifi rate algorithm 
for the link speed ?

Regards,
Marek

  reply	other threads:[~2012-04-02  9:32 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
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 [this message]
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=201204021132.42284.lindner_marek@yahoo.de \
    --to=lindner_marek@yahoo.de \
    --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