From: "Linus Lüssing" <ll@simonwunderlich.de>
To: "Linus Lüssing" <linus.luessing@c0d3.blue>,
"Johannes Berg" <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, b.a.t.m.a.n@lists.open-mesh.org,
Sven Eckelmann <sven@narfation.org>,
Simon Wunderlich <sw@simonwunderlich.de>
Subject: Re: [PATCH] mac80211: mesh: add mesh_param "mesh_nolearn" to skip path discovery
Date: Wed, 17 Jun 2020 09:45:34 +0200 [thread overview]
Message-ID: <6bef8071-f897-b972-dbf9-17198361dc4e@simonwunderlich.de> (raw)
In-Reply-To: <cbe4863e-44f3-c0e4-a4f3-1b0a69f7a386@simonwunderlich.de>
On 16/06/2020 12:16, Linus Lüssing wrote:
>> The new mesh_nolearn parameter allows to skip the PREQ/PREP exchange in
>> this scenario, leading to a reduced delay, reduced packet buffering and
>> simplifies HWMP in general.
And a third observation we've made with HWMP:
When running iperf with 16 parallel TCP streams and the default HWMP
parameters over two 4x4 802.11ac Wave 2 wifi cards transmitting about
800-1000 MBit/s in total, HWMP becomes quite unstable. We see frequent
PREQ/PREP retransmissions and also PERR messages, leading to spurious
break downs in the throughput.
When using just 8 TCP streams, so with a little less saturation and
stress of the channel, iperf staticstics are stable.
So maybe there would be some potential for optimizations, too, like
somehow prioritizing HWMP messages more, or maybe making the default
HWMP parameters a bit more conservative.
Or just disabling the HWMP PREP/PREQ/PERR exchange with this new
configuration option would at least help the ones that are using another
mesh routing protocol on top, who are maybe more familiar with the
parameters of their specific routing protocol than with the HWMP parameters.
Regards, Linus
prev parent reply other threads:[~2020-06-17 7:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 9:53 [PATCH] mac80211: mesh: add mesh_param "mesh_nolearn" to skip path discovery Linus Lüssing
2020-06-16 9:53 ` [PATCH] iw: " Linus Lüssing
2020-06-16 10:16 ` [PATCH] mac80211: " Linus Lüssing
2020-06-17 7:45 ` Linus Lüssing [this message]
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=6bef8071-f897-b972-dbf9-17198361dc4e@simonwunderlich.de \
--to=ll@simonwunderlich.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=johannes@sipsolutions.net \
--cc=linus.luessing@c0d3.blue \
--cc=linux-wireless@vger.kernel.org \
--cc=sven@narfation.org \
--cc=sw@simonwunderlich.de \
/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