public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven@narfation.org>
To: b.a.t.m.a.n@lists.open-mesh.org
Cc: Marek Lindner <mareklindner@neomailbox.ch>,
	Ligang LIU <heishuihe2008@163.com>
Subject: Re: [B.A.T.M.A.N.] [PATCH v5 0/7] B.A.T.M.A.N. V - fallback to tp meter estimation if throughput otherwise not available
Date: Sat, 08 Sep 2018 19:38:01 +0200	[thread overview]
Message-ID: <8046301.0ldSNLAhfO@sven-edge> (raw)
In-Reply-To: <20180907095958.30946-1-mareklindner@neomailbox.ch>

[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]

On Freitag, 7. September 2018 11:59:51 CEST Marek Lindner wrote:
> Under normal circumstances B.A.T.M.A.N. V retrieves the neighbor
> throughput values to populate its metric tables from the various
> drivers such as WiFi throughput tables and Ethernet throughput..
> Whenever the interface drivers do not export link throughput 
> information manual overrides become necessary. To further 
> automate and thus better support these setups, ELP may call the
> batman-adv throughput meter to schedule a throughput estimation
> to be used to populate the metric table.

I know that this patchset is required to have some throughput estimates for 
non-wifi connections (or for wifi drivers without expected throughput). But 
since we have the other discussion with Ligang LIU, I still have to bring this 
up:

We already know that something (maybe ELP unicast probes and the related 
messages) are "breaking" the connectivity between 2 neighbors in Ligang LIU's 
test setup (with 6 not so well connected nodes). It also seems to be the case 
that the driver doesn't return the expected throughput for each neighbor all 
the time and this missing data would then trigger the single-link tpmeter 
test.

The test seem to be done every 60 seconds (or longer when there is another 
source for the throughput) for each neighbor and by default 1s long. My 
assumption would be now that this test could be even more harmful for wifi 
connections than unicast ELP probes (or whatever is causing Ligang LUI's 
problems). Let us just assume that we have these 6 nodes with 5 neighbors (I 
see a lot more in real world setups). If the tests on the different nodes 
don't overlap (which would also be bad for the test results) than all tests 
would take at least 30 seconds of the 60 seconds. So even without the problem 
in the "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing 
Algorithms" mailing list thread, the tpmeter fallback has a significant cost.

Is there anything which I missed that could ease my mind?

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2018-09-08 17:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-07  9:59 [B.A.T.M.A.N.] [PATCH v5 0/7] B.A.T.M.A.N. V - fallback to tp meter estimation if throughput otherwise not available Marek Lindner
2018-09-07  9:59 ` [B.A.T.M.A.N.] [PATCH v5 1/7] batman-adv: tp_meter - prevent concurrent tp_meter sessions by using workqueue Marek Lindner
2018-09-07  9:59 ` [B.A.T.M.A.N.] [PATCH v5 2/7] batman-adv: tp_meter - don't check for existing session Marek Lindner
2018-09-07  9:59 ` [B.A.T.M.A.N.] [PATCH v5 3/7] batman-adv: tp_meter - allow up to 10 queued sessions Marek Lindner
2018-09-07  9:59 ` [B.A.T.M.A.N.] [PATCH v5 4/7] batman-adv: tp_meter - add caller distinction Marek Lindner
2018-09-07  9:59 ` [B.A.T.M.A.N.] [PATCH v5 5/7] batman-adv: tp_meter - add option to perform one-hop test Marek Lindner
2018-09-07  9:59 ` [B.A.T.M.A.N.] [PATCH v5 6/7] batman-adv: ELP - use tp meter to estimate the throughput if otherwise not available Marek Lindner
2018-09-08 17:11   ` Sven Eckelmann
2018-09-07  9:59 ` [B.A.T.M.A.N.] [PATCH v5 7/7] batman-adv: ELP - add throughput meter test duration attribute Marek Lindner
2018-09-08 17:38 ` Sven Eckelmann [this message]
2019-11-25  8:41   ` [B.A.T.M.A.N.] [PATCH v5 0/7] B.A.T.M.A.N. V - fallback to tp meter estimation if throughput otherwise not available 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=8046301.0ldSNLAhfO@sven-edge \
    --to=sven@narfation.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=heishuihe2008@163.com \
    --cc=mareklindner@neomailbox.ch \
    /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