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
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
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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Sat, Jan 28, 2012 at 12:09 PM, Marek Lindner <[email protected]> wrote:
> On Sunday, January 29, 2012 04:03:41 you wrote:
>> On Sat, Jan 28, 2012 at 11:58 AM, Marek Lindner <[email protected]>
> 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
On Sat, Jan 28, 2012 at 10:51 AM, Felix Fietkau <[email protected]> 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
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
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
Signed-off-by: Marek Lindner <[email protected]>
---
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
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 <[email protected]>
>
> 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
On 2012-01-28 8:17 AM, Marek Lindner wrote:
> Signed-off-by: Marek Lindner <[email protected]>
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
On Sat, Jan 28, 2012 at 11:58 AM, Marek Lindner <[email protected]> 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
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 <[email protected]>
>>
>> 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
On Sunday, January 29, 2012 04:03:41 you wrote:
> On Sat, Jan 28, 2012 at 11:58 AM, Marek Lindner <[email protected]>
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
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
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 <[email protected]>
Istituto Superiore Mario Boella