[RFC] minstrel_ht should not override user supplied rts

[RFC] minstrel_ht should not override user supplied rts

[Marek Lindner]

Hi,

I recently noticed that mac80211 ignores my "iw phy0 set rts" setting. It took
me a while to find the culprit - minstrel_ht enables rts/cts by setting
the IEEE80211_TX_RC_USE_RTS_CTS flag in minstrel_ht_set_rate() regardless of 
the rts threshold configured on the commandline. Since I did not find any
explanation why minstrel_ht does what it does I hereby propose a patch to
make minstrel_ht respect the user supplied setting. You will notice the
minstrel_ht_set_rate() function now never is called with rtscts = true. A
future patch will remove this parameter entirely.

Regards,
Marek

[PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Marek Lindner]

Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
---
 net/mac80211/rc80211_minstrel_ht.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index ff5f7b8..9b889d7 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -644,10 +644,10 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
 				false, false);
 		else
 			minstrel_ht_set_rate(mp, mi, &ar[1], mi->max_tp_rate2,
-				false, true);
+				false, false);
 
 		minstrel_ht_set_rate(mp, mi, &ar[2], mi->max_prob_rate,
-				     false, !sample);
+				     false, false);
 
 		ar[3].count = 0;
 		ar[3].idx = -1;
@@ -658,7 +658,7 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
 		 * max_tp_rate -> max_prob_rate by default.
 		 */
 		minstrel_ht_set_rate(mp, mi, &ar[1], mi->max_prob_rate,
-				     false, !sample);
+				     false, false);
 
 		ar[2].count = 0;
 		ar[2].idx = -1;
-- 
1.7.5.4

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Felix Fietkau]

On 2012-01-28 8:17 AM, Marek Lindner wrote:
> Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
NACK, minstrel_ht sets RTS/CTS only from the second rate retry slot on,
to increase the success probability during retransmissions. For the
first slot, it is unset. The user supplied rts setting is not suitable
for configuring RTS/CTS usage this way, so if you want to disable it
entirely, you'd need to add a new setting for that.

- Felix

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Marek Lindner]

On Saturday, January 28, 2012 21:25:39 Felix Fietkau wrote:
> On 2012-01-28 8:17 AM, Marek Lindner wrote:
> > Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
> 
> NACK, minstrel_ht sets RTS/CTS only from the second rate retry slot on,
> to increase the success probability during retransmissions. For the
> first slot, it is unset. The user supplied rts setting is not suitable
> for configuring RTS/CTS usage this way, so if you want to disable it
> entirely, you'd need to add a new setting for that.

If you think it is unsuitable do you mind elaborating what this setting is 
for? As far as I can tell minstrel_ht is the only rate control algorithm that 
decides to be smarter than the user configuring the device. Without mentioning 
this anywhere! IMHO it should be minstrel_ht explaining why this makes sense, 
not the other way round.

Regards,
Marek

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Felix Fietkau]

On 2012-01-28 7:43 PM, Marek Lindner wrote:
> On Saturday, January 28, 2012 21:25:39 Felix Fietkau wrote:
>> On 2012-01-28 8:17 AM, Marek Lindner wrote:
>> > Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
>> 
>> NACK, minstrel_ht sets RTS/CTS only from the second rate retry slot on,
>> to increase the success probability during retransmissions. For the
>> first slot, it is unset. The user supplied rts setting is not suitable
>> for configuring RTS/CTS usage this way, so if you want to disable it
>> entirely, you'd need to add a new setting for that.
> 
> If you think it is unsuitable do you mind elaborating what this setting is 
> for? As far as I can tell minstrel_ht is the only rate control algorithm that 
> decides to be smarter than the user configuring the device. Without mentioning 
> this anywhere! IMHO it should be minstrel_ht explaining why this makes sense, 
> not the other way round.
The user configurable RTS/CTS setting sets a threshold which is applied
to all transmission attempts with a packet size above it.
What minstrel_ht does is enable RTS/CTS only for on-chip retransmissions
of the second rate slot and below. That means as long as it doesn't fall
back to lower rates, no RTS/CTS gets used.
It's not about minstrel_ht being smarter than the user. It's about
adaptive control of RTS/CTS being smarter than a static setting.

- Felix

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Daniel Halperin]

On Sat, Jan 28, 2012 at 10:51 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2012-01-28 7:43 PM, Marek Lindner wrote:
>> On Saturday, January 28, 2012 21:25:39 Felix Fietkau wrote:
>> If you think it is unsuitable do you mind elaborating what this setting is
>> for? As far as I can tell minstrel_ht is the only rate control algorithm that
>> decides to be smarter than the user configuring the device. Without mentioning
>> this anywhere! IMHO it should be minstrel_ht explaining why this makes sense,
>> not the other way round.
> The user configurable RTS/CTS setting sets a threshold which is applied
> to all transmission attempts with a packet size above it.
> What minstrel_ht does is enable RTS/CTS only for on-chip retransmissions
> of the second rate slot and below. That means as long as it doesn't fall
> back to lower rates, no RTS/CTS gets used.
> It's not about minstrel_ht being smarter than the user. It's about
> adaptive control of RTS/CTS being smarter than a static setting.
>

Adaptive RTS/CTS is important to control for interference---RTS/CTS is
there so that other Wi-Fi devices know not to interfere with your
flow. It may well be the case that this is not a major problem in
whatever your scenario you're working, Marek, but it makes a big
difference in a many bad corner cases.

As Felix says, by not forcing RTS/CTS on until a retry, the user's
RTS/CTS preference is used for the overwhelming majority of packets
whose rates are chosen correctly (or a little too slow).

I'm with Felix: I could see adding an option that means "force never
use RTS/CTS" but I think we're at the right operating point when
interpreting the standard "RTS/CTS threshold" option.

(BUT @Felix: maybe max_tp_rate2 shouldn't use RTS/CTS---it's still
trying to be aggressive, whereas max_prob_rate is the one where you
*really* want the packet to get through. So maybe the first half of
Marek's patch is worth keeping, though it *should* be a marginal
difference in normal operating environments.)

Dan

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Felix Fietkau]

On 2012-01-28 8:17 PM, Daniel Halperin wrote:
> (BUT @Felix: maybe max_tp_rate2 shouldn't use RTS/CTS---it's still
> trying to be aggressive, whereas max_prob_rate is the one where you
> *really* want the packet to get through. So maybe the first half of
> Marek's patch is worth keeping, though it *should* be a marginal
> difference in normal operating environments.)
I thought about this as well, but decided to keep it even for
max_tp_rate2, since with long A-MPDUs, the extra time needed by RTS/CTS
compared to the A-MPDU transmission time isn't that much, and
max_prob_rate is usually quite a bit slower.

- Felix

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Marek Lindner]

On Sunday, January 29, 2012 03:17:32 Daniel Halperin wrote:
> Adaptive RTS/CTS is important to control for interference---RTS/CTS is
> there so that other Wi-Fi devices know not to interfere with your
> flow. It may well be the case that this is not a major problem in
> whatever your scenario you're working, Marek, but it makes a big
> difference in a many bad corner cases.

I am very well aware of what RTS/CTS is for and I am not against using it. 
However, having the rate algorithm overriding the user setting for a specific 
rate is extremely hard to grasp or debug.
To give you an understanding where I am coming from: In our networks we 
experienced extremely variable throughput ranging from 30Mbit/s (single 
stream) to 0.2 Mbit/s in the next second. As you can imagine we were trying to 
figure out what was going on. After spending some time and losing hair I 
noticed that the RTS/CTS implementation of our driver (ath9k) is buggy. Every 
once in a while the nodes would "battle" each other with RTS/CTS packets. 
Strange enough for us, sometimes no RTS packets were sent and sometimes they 
would battle. All attempts to disable RTS/CTS for the mere sake of testing(!) 
was impossible. First I thought ath9k did not properly implement the "iw rts" 
setting but that wasn't the case. After losing more hair I realized that 
minstrel_ht, a rate control algorithm(!), was overriding my rts settings but 
not always(!). The only way to make RTS shut up was to apply the posted patch.

We should make a difference between the idea (using RTS to increase the 
reliability) and its implementation. No matter from which angle I look, the 
current implementation gives me much pain.


> I'm with Felix: I could see adding an option that means "force never
> use RTS/CTS" but I think we're at the right operating point when
> interpreting the standard "RTS/CTS threshold" option.

Actually, this option exists already. It's just minstrel_ht overriding it:
iw phy <phyname> set rts <rts threshold|off>
Put special attention towards the "off" at the end.

If we let the rate algorithm override our rts settings it should at least be 
communicated. I found no such mention anywhere. 

I'd like to further stress the point that no other rate algorithm does this. 
We create incoherent and hard to debug behavior.

Regards,
Marek

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Daniel Halperin]

On Sat, Jan 28, 2012 at 11:58 AM, Marek Lindner <lindner_marek@yahoo.de> wrote:
> On Sunday, January 29, 2012 03:17:32 Daniel Halperin wrote:
>> Adaptive RTS/CTS is important to control for interference---RTS/CTS is
>> there so that other Wi-Fi devices know not to interfere with your
>> flow. It may well be the case that this is not a major problem in
>> whatever your scenario you're working, Marek, but it makes a big
>> difference in a many bad corner cases.
>
> I am very well aware of what RTS/CTS is for and I am not against using it.
> However, having the rate algorithm overriding the user setting for a specific
> rate is extremely hard to grasp or debug.
> To give you an understanding where I am coming from: In our networks we
> experienced extremely variable throughput ranging from 30Mbit/s (single
> stream) to 0.2 Mbit/s in the next second. As you can imagine we were trying to
> figure out what was going on. After spending some time and losing hair I
> noticed that the RTS/CTS implementation of our driver (ath9k) is buggy. Every
> once in a while the nodes would "battle" each other with RTS/CTS packets.
> Strange enough for us, sometimes no RTS packets were sent and sometimes they
> would battle. All attempts to disable RTS/CTS for the mere sake of testing(!)
> was impossible. First I thought ath9k did not properly implement the "iw rts"
> setting but that wasn't the case. After losing more hair I realized that
> minstrel_ht, a rate control algorithm(!), was overriding my rts settings but
> not always(!). The only way to make RTS shut up was to apply the posted patch.

Can you explain what the low-level behavior of an RTS/CTS "battle" is?

Abstractly, the behavior you're describing sounds like a buggy driver
that doesn't obey overheard RTS or CTS packets.

Dan

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Marek Lindner]

On Sunday, January 29, 2012 04:03:41 you wrote:
> On Sat, Jan 28, 2012 at 11:58 AM, Marek Lindner <lindner_marek@yahoo.de> 
wrote:
> > On Sunday, January 29, 2012 03:17:32 Daniel Halperin wrote:
> >> Adaptive RTS/CTS is important to control for interference---RTS/CTS is
> >> there so that other Wi-Fi devices know not to interfere with your
> >> flow. It may well be the case that this is not a major problem in
> >> whatever your scenario you're working, Marek, but it makes a big
> >> difference in a many bad corner cases.
> > 
> > I am very well aware of what RTS/CTS is for and I am not against using
> > it. However, having the rate algorithm overriding the user setting for a
> > specific rate is extremely hard to grasp or debug.
> > To give you an understanding where I am coming from: In our networks we
> > experienced extremely variable throughput ranging from 30Mbit/s (single
> > stream) to 0.2 Mbit/s in the next second. As you can imagine we were
> > trying to figure out what was going on. After spending some time and
> > losing hair I noticed that the RTS/CTS implementation of our driver
> > (ath9k) is buggy. Every once in a while the nodes would "battle" each
> > other with RTS/CTS packets. Strange enough for us, sometimes no RTS
> > packets were sent and sometimes they would battle. All attempts to
> > disable RTS/CTS for the mere sake of testing(!) was impossible. First I
> > thought ath9k did not properly implement the "iw rts" setting but that
> > wasn't the case. After losing more hair I realized that minstrel_ht, a
> > rate control algorithm(!), was overriding my rts settings but not
> > always(!). The only way to make RTS shut up was to apply the posted
> > patch.
> 
> Can you explain what the low-level behavior of an RTS/CTS "battle" is?
> 
> Abstractly, the behavior you're describing sounds like a buggy driver
> that doesn't obey overheard RTS or CTS packets.

I certainly can explain it but this is for another thread and unrelated to the 
points raised before.

Regards,
Marek

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Daniel Halperin]

On Sat, Jan 28, 2012 at 12:09 PM, Marek Lindner <lindner_marek@yahoo.de> wrote:
> On Sunday, January 29, 2012 04:03:41 you wrote:
>> On Sat, Jan 28, 2012 at 11:58 AM, Marek Lindner <lindner_marek@yahoo.de>
> wrote:
>> > On Sunday, January 29, 2012 03:17:32 Daniel Halperin wrote:
>> >> Adaptive RTS/CTS is important to control for interference---RTS/CTS is
>> >> there so that other Wi-Fi devices know not to interfere with your
>> >> flow. It may well be the case that this is not a major problem in
>> >> whatever your scenario you're working, Marek, but it makes a big
>> >> difference in a many bad corner cases.
>> >
>> > I am very well aware of what RTS/CTS is for and I am not against using
>> > it. However, having the rate algorithm overriding the user setting for a
>> > specific rate is extremely hard to grasp or debug.
>> > To give you an understanding where I am coming from: In our networks we
>> > experienced extremely variable throughput ranging from 30Mbit/s (single
>> > stream) to 0.2 Mbit/s in the next second. As you can imagine we were
>> > trying to figure out what was going on. After spending some time and
>> > losing hair I noticed that the RTS/CTS implementation of our driver
>> > (ath9k) is buggy. Every once in a while the nodes would "battle" each
>> > other with RTS/CTS packets. Strange enough for us, sometimes no RTS
>> > packets were sent and sometimes they would battle. All attempts to
>> > disable RTS/CTS for the mere sake of testing(!) was impossible. First I
>> > thought ath9k did not properly implement the "iw rts" setting but that
>> > wasn't the case. After losing more hair I realized that minstrel_ht, a
>> > rate control algorithm(!), was overriding my rts settings but not
>> > always(!). The only way to make RTS shut up was to apply the posted
>> > patch.
>>
>> Can you explain what the low-level behavior of an RTS/CTS "battle" is?
>>
>> Abstractly, the behavior you're describing sounds like a buggy driver
>> that doesn't obey overheard RTS or CTS packets.
>
> I certainly can explain it but this is for another thread and unrelated to the
> points raised before.

Frankly, the correctness of your argument depend on whether there's a
bug or not. If the difference is -2% normally and +300% in bad
interference conditions, you're going to lose this debate. If the
difference is legitimately -99% normally, you might win.

Your description reminds me of this:
http://www.spinics.net/lists/linux-wireless/msg83803.html. Maybe there
really is a bug in ath9k.

Dan

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Marek Lindner]

On Sunday, January 29, 2012 04:26:29 Daniel Halperin wrote:
> >> Can you explain what the low-level behavior of an RTS/CTS "battle" is?
> >> 
> >> Abstractly, the behavior you're describing sounds like a buggy driver
> >> that doesn't obey overheard RTS or CTS packets.
> > 
> > I certainly can explain it but this is for another thread and unrelated
> > to the points raised before.
> 
> Frankly, the correctness of your argument depend on whether there's a
> bug or not. If the difference is -2% normally and +300% in bad
> interference conditions, you're going to lose this debate. If the
> difference is legitimately -99% normally, you might win.

I don't quite follow you here. Are you saying it should only be possible to 
disable rts/cts if I currently have a bug in my rts/cts implementation ?

Keep in mind that I am not asking to disable/ban rts/cts for everyone. I'd 
like minstrel_ht to not override my rts/cts setting if I wish to disable it.

Regards,
Marek

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

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" ?

Cheers,
        Simon

On Sun, Jan 29, 2012 at 04:35:13AM +0800, Marek Lindner wrote:
> On Sunday, January 29, 2012 04:26:29 Daniel Halperin wrote:
> > >> Can you explain what the low-level behavior of an RTS/CTS "battle" is?
> > >> 
> > >> Abstractly, the behavior you're describing sounds like a buggy driver
> > >> that doesn't obey overheard RTS or CTS packets.
> > > 
> > > I certainly can explain it but this is for another thread and unrelated
> > > to the points raised before.
> > 
> > Frankly, the correctness of your argument depend on whether there's a
> > bug or not. If the difference is -2% normally and +300% in bad
> > interference conditions, you're going to lose this debate. If the
> > difference is legitimately -99% normally, you might win.
> 
> I don't quite follow you here. Are you saying it should only be possible to 
> disable rts/cts if I currently have a bug in my rts/cts implementation ?
> 
> Keep in mind that I am not asking to disable/ban rts/cts for everyone. I'd 
> like minstrel_ht to not override my rts/cts setting if I wish to disable it.
> 
> Regards,
> Marek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Felix Fietkau]

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

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Felix Fietkau]

On 2012-01-28 8:58 PM, Marek Lindner wrote:
>> I'm with Felix: I could see adding an option that means "force never
>> use RTS/CTS" but I think we're at the right operating point when
>> interpreting the standard "RTS/CTS threshold" option.
> 
> Actually, this option exists already. It's just minstrel_ht overriding it:
> iw phy <phyname> set rts <rts threshold|off>
> Put special attention towards the "off" at the end.
> 
> If we let the rate algorithm override our rts settings it should at least be 
> communicated. I found no such mention anywhere. 
> 
> I'd like to further stress the point that no other rate algorithm does this. 
> We create incoherent and hard to debug behavior.
Which rate algorithms did you check to come to that conclusion? I just
looked at the ath9k rate control algorithm and it does the same ;)

- Felix

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Marek Lindner]

On Sunday, January 29, 2012 04:20:24 you wrote:
> On 2012-01-28 8:58 PM, Marek Lindner wrote:
> >> I'm with Felix: I could see adding an option that means "force never
> >> use RTS/CTS" but I think we're at the right operating point when
> >> interpreting the standard "RTS/CTS threshold" option.
> > 
> > Actually, this option exists already. It's just minstrel_ht overriding
> > it: iw phy <phyname> set rts <rts threshold|off>
> > Put special attention towards the "off" at the end.
> > 
> > If we let the rate algorithm override our rts settings it should at least
> > be communicated. I found no such mention anywhere.
> > 
> > I'd like to further stress the point that no other rate algorithm does
> > this. We create incoherent and hard to debug behavior.
> 
> Which rate algorithms did you check to come to that conclusion? I just
> looked at the ath9k rate control algorithm and it does the same ;)

I checked net/mac80211/rc80211_* since that is where minstrel_ht is living.

Regards,
Marek

iwlwifi updates for 3.6

[Johannes Berg]

Here's another set of iwlwifi updates. We continue some refactoring
and have a bunch of random updates all over.

I'll submit a pull request in a few days, but only after my you pull
my previous request, and maybe I'll combine more patches in too.

johannes

[PATCH 09/13] iwlwifi: comment that setting driver_data overrides info->control

[Johannes Berg]

From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Using the driver_data area in ieee80211_tx_info which
resides in the CB overrides the info->control field.
Add a comment to prevent mistakes.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 drivers/net/wireless/iwlwifi/dvm/tx.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/iwlwifi/dvm/tx.c b/drivers/net/wireless/iwlwifi/dvm/tx.c
index 0dfaf64..1f9457f 100644
--- a/drivers/net/wireless/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
@@ -403,6 +403,7 @@ int iwlagn_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
 
 	info->driver_data[0] = ctx;
 	info->driver_data[1] = dev_cmd;
+	/* From now on, we cannot access info->control */
 
 	spin_lock(&priv->sta_lock);
 
-- 
1.7.10

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Guido Gavilanes]

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

Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting

[Guido Gavilanes]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

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
dissappeared
only for low traffic demands from upper layers (around 1Mbps  with 3
nodes). Testing with 3 Mbps makes the RTS appear despite the RTS "off"
setting from iw.
Is there a way to set minstrel_ht not to use RTS (no matter the clever
or not it be) ?
I have searched for a while on the archive but this seems the only
conversation that deals with that.

Thank you very much for any information!
Guido

-- 
Guido Gavilanes <gavilanes@ismb.it>
Istituto Superiore Mario Boella


[-- Attachment #2: Forwarded message - Re: [PATCH] mac80211: minstrel_ht should not override user supplied rts setting --]
[-- Type: message/rfc822, Size: 2452 bytes --]

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
Message-ID: <1411467050.11571.47.camel@MacGyver>

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