ath5k: Use high bitrates for ACK/CTS

PATCH In review Bruno Randolf 3 participants 5 messages Apr 12, 2010 – Apr 19, 2010 Atheros ATH5K wireless driver

Share & tools

Bruno Randolf

author

2010-04-12 07:38 UTC #0 lore raw

PATCH 1/2 ath5k: Use high bitrates for ACK/CTS

There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually resulted in high bitrates, which i think is what we want anyways. Cleared the confusion and added some documentation.

Signed-off-by Bruno Randolf <[email protected]>

---
 drivers/net/wireless/ath/ath5k/base.c |    3 +--
 drivers/net/wireless/ath/ath5k/pcu.c  |    4 ++--
 drivers/net/wireless/ath/ath5k/reg.h  |    4 ++--
 3 files changed, 5 insertions(+), 6 deletions(-)

drivers/net/wireless/ath/ath5k/base.c +1 -2

index f7f57c1..3f59bc2 100644
@@ -2558,8 +2558,7 @@ ath5k_init(struct ath5k_softc *sc)
 	for (i = 0; i < AR5K_KEYTABLE_SIZE; i++)
 		ath5k_hw_reset_key(ah, i);
 
-	/* Set ack to be sent at low bit-rates */
-	ath5k_hw_set_ack_bitrate_high(ah, false);
+	ath5k_hw_set_ack_bitrate_high(ah, true);
 	ret = 0;
 done:
 	mmiowb();

drivers/net/wireless/ath/ath5k/pcu.c +2 -2

index 710870e..174412f 100644
@@ -154,9 +154,9 @@ void ath5k_hw_set_ack_bitrate_high(struct ath5k_hw *ah, bool high)
 	else {
 		u32 val = AR5K_STA_ID1_BASE_RATE_11B | AR5K_STA_ID1_ACKCTS_6MB;
 		if (high)
-			AR5K_REG_ENABLE_BITS(ah, AR5K_STA_ID1, val);
-		else
 			AR5K_REG_DISABLE_BITS(ah, AR5K_STA_ID1, val);
+		else
+			AR5K_REG_ENABLE_BITS(ah, AR5K_STA_ID1, val);
 	}
 }

drivers/net/wireless/ath/ath5k/reg.h +2 -2

index 45d62e9..55b4ac6 100644
@@ -1139,8 +1139,8 @@
 #define AR5K_STA_ID1_DEFAULT_ANTENNA	0x00200000	/* Use default antenna */
 #define AR5K_STA_ID1_DESC_ANTENNA	0x00400000	/* Update antenna from descriptor */
 #define AR5K_STA_ID1_RTS_DEF_ANTENNA	0x00800000	/* Use default antenna for RTS */
-#define AR5K_STA_ID1_ACKCTS_6MB		0x01000000	/* Use 6Mbit/s for ACK/CTS */
-#define AR5K_STA_ID1_BASE_RATE_11B	0x02000000	/* Use 11b base rate for ACK/CTS [5211+] */
+#define AR5K_STA_ID1_ACKCTS_6MB		0x01000000	/* Rate to use for ACK/CTS. 0: highest mandatory rate <= RX rate; 1: 1Mbps in B mode */
+#define AR5K_STA_ID1_BASE_RATE_11B	0x02000000	/* 802.11b base rate. 0: 1, 2, 5.5 and 11Mbps; 1: 1 and 2Mbps. [5211+] */
 #define AR5K_STA_ID1_SELFGEN_DEF_ANT	0x04000000	/* Use def. antenna for self generated frames */
 #define AR5K_STA_ID1_CRYPT_MIC_EN	0x08000000	/* Enable MIC */
 #define AR5K_STA_ID1_KEYSRCH_MODE	0x10000000	/* Look up key when key id != 0 */

Bruno Randolf

author

2010-04-12 07:38 UTC #1 lore raw

PATCH 2/2 ath5k: treat RXORN as non-fatal

We get RXORN interrupts when all receive buffers are full. This is not necessarily a fatal situation. It can also happen when the bus is busy or the CPU is not fast enough to process all frames.

Older chipsets apparently need a reset to come out of this situration, but on newer chips we can treat RXORN like RX, as going thru a full reset does more harm than good, there.

The exact chip revisions which need a reset are unknown - this guess AR5K_SREV_AR5212 ("venice") is copied from the HAL.

Inspired by openwrt 413-rxorn.patch:
"treat rxorn like rx, reset after rxorn seems to do more harm than good"

Signed-off-by Bruno Randolf <[email protected]>

---
 drivers/net/wireless/ath/ath5k/base.c |   15 ++++++++++++++-
 drivers/net/wireless/ath/ath5k/base.h |    1 +
 2 files changed, 15 insertions(+), 1 deletions(-)

drivers/net/wireless/ath/ath5k/base.c +14 -1

index 3f59bc2..9232742 100644
@@ -2705,7 +2705,20 @@ ath5k_intr(int irq, void *dev_id)
 			 */
 			tasklet_schedule(&sc->restq);
 		} else if (unlikely(status & AR5K_INT_RXORN)) {
-			tasklet_schedule(&sc->restq);
+			/*
+			 * Receive buffers are full. Either the bus is busy or
+			 * the CPU is not fast enough to process all received
+			 * frames.
+			 * Older chipsets need a reset to come out of this
+			 * condition, but we treat it as RX for newer chips.
+			 * We don't know exactly which versions need a reset -
+			 * this guess is copied from the HAL.
+			 */
+			sc->stats.rxorn_intr++;
+			if (ah->ah_mac_srev < AR5K_SREV_AR5212)
+				tasklet_schedule(&sc->restq);
+			else
+				tasklet_schedule(&sc->rxtq);
 		} else {
 			if (status & AR5K_INT_SWBA) {
 				tasklet_hi_schedule(&sc->beacontq);

drivers/net/wireless/ath/ath5k/base.h +1 -0

index 53a5651..56221bc 100644
@@ -135,6 +135,7 @@ struct ath5k_statistics {
 	unsigned int beacons;
 
 	unsigned int mib_intr;
+	unsigned int rxorn_intr;
 };
 
 #if CHAN_DEBUG

Stanislaw Gruszka

2010-04-16 13:57 UTC #2 lore raw

In reply to Bruno Randolf

Quoted 5 lines · On Mon, 12 Apr 2010 16:38:47 +0900 Bruno Randolf <[email protected]> wrote:

There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually resulted in high bitrates, which i think is what we want anyways. Cleared the confusion and added some documentation.

I thought ACK and other control frames have to be modulated at slow/robust bitrates, but can't remember where I read that ...

Stanislaw

Bruno Randolf

author

2010-04-19 00:24 UTC #3 lore raw

Quoted 11 lines · On Friday 16 April 2010 22:59:07 Stanislaw Gruszka wrote:

On Mon, 12 Apr 2010 16:38:47 +0900
Quoted 5 lines · Bruno Randolf
There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually resulted in high bitrates, which i think is what we want anyways. Cleared the confusion and added some documentation.
I thought ACK and other control frames have to be modulated at slow/robust bitrates, but can't remember where I read that ...

this has been discussed on ath5k-devel before. i'm copying it here. please let me know if i missed something...

(https://lists.ath5k.org/pipermail/ath5k-devel/2010-March/003391.html)

control frames have to be sent at one of the lower bitrates - one of the "basic rates". in G mode these are 1, 2, 5.5, 11, 6, 12, 24Mbps.

this is from the 802.11g spec:
"a STA responding to a received frame shall transmit its Control Response (either CTS or ACK) frames at the highest rate in the BSSBasicRateSet that is less than or equal to the rate of the immediately previous frame in the frame exchange sequence (as defined in 9.7)"

basically we have to make a tradeoff here: using lower rates for ACK/CTS will improve reliability, but lower performance. for example i could get only 10Mbps truput with ACK/CTS at the lowest bitrates and RTS/CTS enabled (iwconfig wlan0 rts 250) and i can get more than 20Mbps with higher bitrates. so i think it's worth to use high bitrates. actually also this should be tuneable for the user, too...

bruno

Gábor Stefanik

2010-04-19 10:15 UTC #4 lore raw

Quoted 13 lines · Bruno Randolf

Quoted 11 lines · On Friday 16 April 2010 22:59:07 Stanislaw Gruszka wrote:
On Mon, 12 Apr 2010 16:38:47 +0900
Quoted 5 lines · Bruno Randolf
There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually resulted in high bitrates, which i think is what we want anyways. Cleared the confusion and added some documentation.
I thought ACK and other control frames have to be modulated at slow/robust bitrates, but can't remember where I read that ...

Quoted 7 lines

this has been discussed on ath5k-devel before. i'm copying it here. please let me know if i missed something...
(https://lists.ath5k.org/pipermail/ath5k-devel/2010-March/003391.html)
control frames have to be sent at one of the lower bitrates - one of the "basic rates". in G mode these are 1, 2, 5.5, 11, 6, 12, 24Mbps.

Aren't basic rates defined so as to exclude any OFDM rates? I.e. are 6M, 12M and 24M really basic rates?

Quoted 20 lines

this is from the 802.11g spec:
"a STA responding to a received frame shall transmit its Control Response (either CTS or ACK) frames at the highest rate in the BSSBasicRateSet that is less than or equal to the rate of the immediately previous frame in the frame exchange sequence (as defined in 9.7)"
basically we have to make a tradeoff here: using lower rates for ACK/CTS will improve reliability, but lower performance. for example i could get only 10Mbps truput with ACK/CTS at the lowest bitrates and RTS/CTS enabled (iwconfig wlan0 rts 250) and i can get more than 20Mbps with higher bitrates. so i think it's worth to use high bitrates. actually also this should be tuneable for the user, too...
bruno
--
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

Signature · 1 line

Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)