From: Guido Gavilanes <gavilanes@ismb.it>
To: linux-wireless@vger.kernel.org
Cc: nbd@openwrt.org, simon.wunderlich@s2003.tu-chemnitz.de,
lindner_marek@yahoo.de
Subject: Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting
Date: Tue, 23 Sep 2014 12:10:50 +0200 [thread overview]
Message-ID: <1411467050.11571.47.camel@MacGyver> (raw)
In-Reply-To: <1339408392-19425-10-git-send-email-johannes@sipsolutions.net>
I write here since I am currently performing experiments in which I need
specifically to disable RTS frames. Intuitively, I tried to set
iw phyXX set rts off
but btained counter-intuitive results, since RTS effectively dissappear
only for low traffic demands from upper layers (around 1Mbps with 3
nodes). Testing with 3 Mbps make the RTS appeared despite the RTS
setting.
Is there a way to set minstrel_ht not to use RTS (no matter the clever
or not it is) ?
I have searched a bit on the archive but this seems the only
conversation that deals with that.
Thank you very much for any information!
Gui
On 2012-01-28 11:14 PM, Simon Wunderlich wrote:
> I agree to Marek here - if I want to disable RTS (for whatever
reason), I type
>
> iw phy0 set rts off
>
> I would expect to see no RTS frames coming from my WiFi card at all.
If the
> rate control algorithm (whether ath9k or minstrel_ht) wants to be
clever, it should
> still respect this decision. The oven in my kitchen also has a
temperature regulator,
> but if I turn it off I also don't want my oven to be too clever and
burn down the house. ;)
>
> I know, apples and oranges, but I hope this makes this point
understandable. I also
> had quite a debugging night to find the reason for these "wild rts"
frames.
>
> Can't we add something two states, like:
> * "RTS really off" and
> * "RTS usually off, but rc's may still use it" ?
If you send a patch for that, I'm ok with it. The default should be RTS
off, but rc may still use it.
- Feli
--
To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-09-23 10:38 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 9:52 iwlwifi updates for 3.6 Johannes Berg
2012-06-11 9:53 ` [PATCH 01/13] iwlwifi: refactor testmode Johannes Berg
2012-06-11 9:53 ` [PATCH 02/13] iwlwifi: decouple testmode and iwl-test Johannes Berg
2012-06-11 9:53 ` [PATCH 03/13] iwlwifi: fix dynamic loading Johannes Berg
2012-06-11 9:53 ` [PATCH 04/13] iwlwifi: s/iwl_read_targ_mem_words/iwl_read_targ_mem_bytes Johannes Berg
2012-06-11 9:53 ` [PATCH 05/13] iwlwifi: iwl_{read,write}_targ_mem_words takes dwords Johannes Berg
2012-06-11 9:53 ` [PATCH 06/13] iwlwifi: print more info when a queue is stuck Johannes Berg
2012-06-11 9:53 ` [PATCH 07/13] iwlwifi: don't configure a txq that is being disabled Johannes Berg
2012-06-11 9:53 ` [PATCH 08/13] iwlwifi: remove lock around txq_enable Johannes Berg
2012-06-11 9:53 ` [PATCH 09/13] iwlwifi: comment that setting driver_data overrides info->control Johannes Berg
2014-09-23 10:10 ` Guido Gavilanes [this message]
2012-06-11 9:53 ` [PATCH 10/13] iwlwifi: Fix Makefile build order for built-in driver Johannes Berg
2012-06-11 9:53 ` [PATCH 11/13] iwlwifi: print even more info when a queue is stuck Johannes Berg
2012-06-11 9:53 ` [PATCH 12/13] iwlwifi: turn on a lockdep assertion Johannes Berg
2012-06-11 9:53 ` [PATCH 13/13] iwlwifi: don't modify the timer if we don't Tx Johannes Berg
2012-06-12 19:57 ` iwlwifi updates for 3.6 Johannes Berg
2012-06-13 6:13 ` Johannes Berg
-- strict thread matches above, loose matches on Subject: below --
2014-09-23 11:44 [PATCH] mac80211: minstrel_ht should not override user supplied rts setting Guido Gavilanes
2012-01-28 7:17 [RFC] minstrel_ht should not override user supplied rts Marek Lindner
2012-01-28 7:17 ` [PATCH] mac80211: minstrel_ht should not override user supplied rts setting Marek Lindner
2012-01-28 13:25 ` Felix Fietkau
2012-01-28 18:43 ` Marek Lindner
2012-01-28 18:51 ` Felix Fietkau
2012-01-28 19:17 ` Daniel Halperin
2012-01-28 19:28 ` Felix Fietkau
2012-01-28 19:58 ` Marek Lindner
2012-01-28 20:03 ` Daniel Halperin
2012-01-28 20:09 ` Marek Lindner
2012-01-28 20:26 ` Daniel Halperin
2012-01-28 20:35 ` Marek Lindner
2012-01-28 22:14 ` Simon Wunderlich
2012-01-29 2:36 ` Felix Fietkau
2012-01-28 20:20 ` Felix Fietkau
2012-01-28 20:23 ` Marek Lindner
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=1411467050.11571.47.camel@MacGyver \
--to=gavilanes@ismb.it \
--cc=lindner_marek@yahoo.de \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@openwrt.org \
--cc=simon.wunderlich@s2003.tu-chemnitz.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;
as well as URLs for NNTP newsgroup(s).