From: Marek Lindner <mareklindner@neomailbox.ch>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] [PATCH v2 7/7] batman-adv: ELP - add throughput meter test duration attribute
Date: Sat, 04 Aug 2018 17:05:42 +0800 [thread overview]
Message-ID: <42613698.Wqezz8BKG2@rousseau> (raw)
In-Reply-To: <20180521134657.GL7162@otheros>
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
On Monday, 21 May 2018 21:46:57 HKT Linus Lüssing wrote:
> On Fri, May 18, 2018 at 09:47:54AM +0800, Marek Lindner wrote:
> > When the ELP throughput meter fallback kicks in to trigger
> > a throughput meter measurement the test duration can be
> > configured via this attribute.
> >
> > Default tp test duration: 1000ms
>
> Would it make sense to note the adjusted default tp test duration
> in the commit message, too? It is adjusted from 10ms to 1000ms
> here, right?
I am having a hard time following your thoughts here. The default duration is
part of the commit message. The user space tp meter test is not affected by
this change. The tp meter ELP duration of 10ms default was introduced in the
previous patch only.
Anyway, will change the previous patch to use 1000ms.
> I'm also wondering if it would make sense to make the test
> interval adjustable instead of the duration:
>
> With 1000ms on a 16MBit/s DSL line this would generate 864GB of
> traffic per month and would be an issue for several existing
> setups right now.
Assuming you are talking about the batman-adv-over-VPN-over-internet use-case:
Simply set the interface throughput to 16MBit/s to disable the ELP throughput
meter measuring altogether (see throughput_override).
ELP throughput measuring is not built to improve that use-case.
> Is there some minimum test duration at which the tp meter is
> supposed to not work realiably anymore, where an increased check
> period would be more suitable?
The ELP throughput meter test is designed to handle interface / neighbors with
fluctuating link throughput. For those setups, having up-to-date link
throughput information is what makes this worthwhile.
Static DSL uplinks don't fall into that category. Every regular throughput
check (no matter how rare) is worse than no test at all. To handle those case,
batman-adv already provides a knob.
Cheers,
Marek
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-08-04 9:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 1:47 [B.A.T.M.A.N.] [PATCH v2 0/7] B.A.T.M.A.N. V - fallback to tp meter estimation if throughput otherwise not available Marek Lindner
2018-05-18 1:47 ` [B.A.T.M.A.N.] [PATCH v2 1/7] batman-adv: tp_meter - prevent concurrent tp_meter sessions by using workqueue Marek Lindner
2018-08-29 6:56 ` Sven Eckelmann
2018-05-18 1:47 ` [B.A.T.M.A.N.] [PATCH v2 2/7] batman-adv: tp_meter - don't check for existing session Marek Lindner
2018-05-18 1:47 ` [B.A.T.M.A.N.] [PATCH v2 3/7] batman-adv: tp_meter - allow up to 10 queued sessions Marek Lindner
2018-05-18 1:47 ` [B.A.T.M.A.N.] [PATCH v2 4/7] batman-adv: tp_meter - add caller distinction Marek Lindner
2018-05-18 1:47 ` [B.A.T.M.A.N.] [PATCH v2 5/7] batman-adv: tp_meter - add option to perform one-hop test Marek Lindner
2018-05-18 1:47 ` [B.A.T.M.A.N.] [PATCH v2 6/7] batman-adv: ELP - use tp meter to estimate the throughput if otherwise not available Marek Lindner
2018-05-21 13:17 ` Linus Lüssing
2018-05-21 17:51 ` Sven Eckelmann
2018-05-21 19:06 ` Sven Eckelmann
2018-08-04 9:31 ` Antonio Quartulli
2018-05-21 14:43 ` Linus Lüssing
2018-08-04 9:35 ` Marek Lindner
2018-05-21 14:48 ` Linus Lüssing
2018-08-04 9:39 ` Antonio Quartulli
2018-05-21 15:01 ` Linus Lüssing
2018-08-04 8:59 ` Antonio Quartulli
2018-05-21 16:36 ` Sven Eckelmann
2018-05-18 1:47 ` [B.A.T.M.A.N.] [PATCH v2 7/7] batman-adv: ELP - add throughput meter test duration attribute Marek Lindner
2018-05-21 13:46 ` Linus Lüssing
2018-05-21 13:57 ` Linus Lüssing
2018-08-04 9:05 ` Marek Lindner [this message]
2018-05-21 14:34 ` Sven Eckelmann
2018-08-04 8:41 ` Antonio Quartulli
2018-08-04 9:02 ` Sven Eckelmann
2018-08-04 9:08 ` Antonio Quartulli
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=42613698.Wqezz8BKG2@rousseau \
--to=mareklindner@neomailbox.ch \
--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;
as well as URLs for NNTP newsgroup(s).