public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
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

      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