From: Johannes Berg <johannes@sipsolutions.net>
To: Masashi Honma <masashi.honma@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/2] mac80211: Drop new node with weak power
Date: Thu, 16 Mar 2017 11:03:50 +0100 [thread overview]
Message-ID: <1489658630.2370.4.camel@sipsolutions.net> (raw)
In-Reply-To: <1489629438-7087-2-git-send-email-masashi.honma@gmail.com> (sfid-20170316_025743_262084_63875C60)
Hi,
On Thu, 2017-03-16 at 10:57 +0900, Masashi Honma wrote:
> On some practical cases, it is useful to drop new node in the
> distance.
> Because mesh metric is calculated with hop count and without RSSI
> information, a node far from local peer and near to destination node
> could be used as best path.
>
> For example, the nodes are located in linear. Distance of 0 - 1 and
> 1 - 2 and 2 - 3 is 20meters. 0 to 3 signal is very weak.
>
> 0 --- 1 --- 2 --- 3
>
> Though most robust path from 0 to 3 is 0 -> 1 -> 2 -> 3,
> unfortunately, node 0 could recognize node 3 as neighbor. Then node 3
> could be next of node 0. This patch aims to avoid such a case.
I'm not really sure this is the right solution?
It seems to me that it should be a function of the path selection to
take this into account, not prohibiting the longer path entirely?
It seems that this is really what the meshcfg.rssi_threshold was
intended for, and the plink code *does* take it into account. Can you
explain where that's breaking down?
The documentation for this als talks about it being a plink threshold,
so I'm not really sure we should use it to kick out stations entirely.
johannes
next prev parent reply other threads:[~2017-03-16 10:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-16 1:57 [PATCH 1/2] nl80211: Use signed function for a signed variable Masashi Honma
2017-03-16 1:57 ` [PATCH 2/2] mac80211: Drop new node with weak power Masashi Honma
2017-03-16 10:03 ` Johannes Berg [this message]
2017-03-17 5:56 ` Masashi Honma
2017-03-17 12:28 ` Johannes Berg
2017-03-20 6:39 ` Masashi Honma
2017-03-29 8:26 ` Johannes Berg
2017-03-16 9:55 ` [PATCH 1/2] nl80211: Use signed function for a signed variable Johannes Berg
2017-03-17 5:59 ` [PATCH v2] mac80211: Use rssi_threshold even though user_mpm=1 Masashi Honma
2017-03-26 20:53 ` Masashi Honma
2017-03-29 8:29 ` Johannes Berg
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=1489658630.2370.4.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=masashi.honma@gmail.com \
/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).