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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.