[PATCH 1/2] ath9k_hw: Fix rx latency of 11a mode

[PATCH 1/2] ath9k_hw: Fix rx latency of 11a mode

[Rajkumar Manoharan]

Rx latecy to start signal(usec) of 11a is 41 not 37 and
also corrected the rx delay in quarter rate.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath9k/hw.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 88100cc..d4dce6b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -974,7 +974,10 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
 	if (ah->misc_mode != 0)
 		REG_SET_BIT(ah, AR_PCU_MISC, ah->misc_mode);
 
-	rx_lat = 37;
+	if (IS_CHAN_A_FAST_CLOCK(ah, chan))
+		rx_lat = 41;
+	else
+		rx_lat = 37;
 	tx_lat = 54;
 
 	if (IS_CHAN_HALF_RATE(chan)) {
@@ -988,7 +991,7 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
 		sifstime = 32;
 	} else if (IS_CHAN_QUARTER_RATE(chan)) {
 		eifs = 340;
-		rx_lat *= 4;
+		rx_lat *= 4 - 1;
 		tx_lat *= 4;
 		if (IS_CHAN_A_FAST_CLOCK(ah, chan))
 		    tx_lat += 22;
-- 
1.7.6.1

[PATCH 2/2] ath9k_hw: Fix slottime with coverage class

[Rajkumar Manoharan]

The commit b6ba41bb27eb9810d54e2301355ce56fd0e94a1a updates
acktimeout wihout updating slottime when coverage class is defined
as per IEEE 802.11-2007 17.3.8.6.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath9k/hw.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index d4dce6b..9936b68 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1012,7 +1012,8 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
 	}
 
 	/* As defined by IEEE 802.11-2007 17.3.8.6 */
-	acktimeout = slottime + sifstime + 3 * ah->coverage_class;
+	slottime = ah->slottime + 3 * ah->coverage_class;
+	acktimeout = slottime + sifstime;
 
 	/*
 	 * Workaround for early ACK timeouts, add an offset to match the
-- 
1.7.6.1

Re: [PATCH 2/2] ath9k_hw: Fix slottime with coverage class

[Felix Fietkau]

On 2011-08-25 4:45 PM, Rajkumar Manoharan wrote:
> The commit b6ba41bb27eb9810d54e2301355ce56fd0e94a1a updates
> acktimeout wihout updating slottime when coverage class is defined
> as per IEEE 802.11-2007 17.3.8.6.
>
> Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
I intentionally left the coverage class out of the hw slot time setting, 
because increasing slot time too much causes severe throughput issues. 
I've observed this even with relatively minor coverage class settings 
(e.g. for 2 km) on AR9160 and AR9280. I haven't tested AR9380 though.

- Felix

Re: [PATCH 2/2] ath9k_hw: Fix slottime with coverage class

[Rajkumar Manoharan]

On Thu, Aug 25, 2011 at 05:36:03PM +0200, Felix Fietkau wrote:
> On 2011-08-25 4:45 PM, Rajkumar Manoharan wrote:
> >The commit b6ba41bb27eb9810d54e2301355ce56fd0e94a1a updates
> >acktimeout wihout updating slottime when coverage class is defined
> >as per IEEE 802.11-2007 17.3.8.6.
> >
> >Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
> I intentionally left the coverage class out of the hw slot time
> setting, because increasing slot time too much causes severe
> throughput issues. I've observed this even with relatively minor
> coverage class settings (e.g. for 2 km) on AR9160 and AR9280. I
> haven't tested AR9380 though.
>
Which band have you tested on AR9280?

--
Rajkumar

Re: [PATCH 2/2] ath9k_hw: Fix slottime with coverage class

[Felix Fietkau]

On 2011-08-26 3:32 PM, Rajkumar Manoharan wrote:
> On Thu, Aug 25, 2011 at 05:36:03PM +0200, Felix Fietkau wrote:
>>  On 2011-08-25 4:45 PM, Rajkumar Manoharan wrote:
>>  >The commit b6ba41bb27eb9810d54e2301355ce56fd0e94a1a updates
>>  >acktimeout wihout updating slottime when coverage class is defined
>>  >as per IEEE 802.11-2007 17.3.8.6.
>>  >
>>  >Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
>>  I intentionally left the coverage class out of the hw slot time
>>  setting, because increasing slot time too much causes severe
>>  throughput issues. I've observed this even with relatively minor
>>  coverage class settings (e.g. for 2 km) on AR9160 and AR9280. I
>>  haven't tested AR9380 though.
>>
> Which band have you tested on AR9280?
Both.

Re: [PATCH 2/2] ath9k_hw: Fix slottime with coverage class

[Rajkumar Manoharan]

On Fri, Aug 26, 2011 at 05:00:04PM +0200, Felix Fietkau wrote:
> On 2011-08-26 3:32 PM, Rajkumar Manoharan wrote:
> >On Thu, Aug 25, 2011 at 05:36:03PM +0200, Felix Fietkau wrote:
> >> On 2011-08-25 4:45 PM, Rajkumar Manoharan wrote:
> >> >The commit b6ba41bb27eb9810d54e2301355ce56fd0e94a1a updates
> >> >acktimeout wihout updating slottime when coverage class is defined
> >> >as per IEEE 802.11-2007 17.3.8.6.
> >> >
> >> >Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
> >> I intentionally left the coverage class out of the hw slot time
> >> setting, because increasing slot time too much causes severe
> >> throughput issues. I've observed this even with relatively minor
> >> coverage class settings (e.g. for 2 km) on AR9160 and AR9280. I
> >> haven't tested AR9380 though.
> >>
> >Which band have you tested on AR9280?
> Both.
IIRC, the scope of section 17 is meant for 5GHz alone. isn't it?

--
Rajkumar

Re: [PATCH 2/2] ath9k_hw: Fix slottime with coverage class

[Felix Fietkau]

On 2011-08-26 5:20 PM, Rajkumar Manoharan wrote:
> On Fri, Aug 26, 2011 at 05:00:04PM +0200, Felix Fietkau wrote:
>>  On 2011-08-26 3:32 PM, Rajkumar Manoharan wrote:
>>  >On Thu, Aug 25, 2011 at 05:36:03PM +0200, Felix Fietkau wrote:
>>  >>  On 2011-08-25 4:45 PM, Rajkumar Manoharan wrote:
>>  >>  >The commit b6ba41bb27eb9810d54e2301355ce56fd0e94a1a updates
>>  >>  >acktimeout wihout updating slottime when coverage class is defined
>>  >>  >as per IEEE 802.11-2007 17.3.8.6.
>>  >>  >
>>  >>  >Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
>>  >>  I intentionally left the coverage class out of the hw slot time
>>  >>  setting, because increasing slot time too much causes severe
>>  >>  throughput issues. I've observed this even with relatively minor
>>  >>  coverage class settings (e.g. for 2 km) on AR9160 and AR9280. I
>>  >>  haven't tested AR9380 though.
>>  >>
>>  >Which band have you tested on AR9280?
>>  Both.
> IIRC, the scope of section 17 is meant for 5GHz alone. isn't it?
Could be, but it doesn't make much sense to make the coverage class 
setting dependent on 5 GHz. 2.4 GHz is actively being used (also with 
ath9k) for long distance links as well.
The way the coverage class setting is implemented in ath9k at the moment 
works just fine and is tested for both 2.4 GHz and 5 GHz.

- Felix

Re: [PATCH 1/2] ath9k_hw: Fix rx latency of 11a mode

[Felix Fietkau]

On 2011-08-25 4:45 PM, Rajkumar Manoharan wrote:
> Rx latecy to start signal(usec) of 11a is 41 not 37 and
> also corrected the rx delay in quarter rate.
>
> Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath9k/hw.c |    7 +++++--
>   1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
> index 88100cc..d4dce6b 100644
> --- a/drivers/net/wireless/ath/ath9k/hw.c
> +++ b/drivers/net/wireless/ath/ath9k/hw.c
> @@ -974,7 +974,10 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
>   	if (ah->misc_mode != 0)
>   		REG_SET_BIT(ah, AR_PCU_MISC, ah->misc_mode);
>
> -	rx_lat = 37;
> +	if (IS_CHAN_A_FAST_CLOCK(ah, chan))
> +		rx_lat = 41;
> +	else
> +		rx_lat = 37;
>   	tx_lat = 54;
>
>   	if (IS_CHAN_HALF_RATE(chan)) {
> @@ -988,7 +991,7 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
>   		sifstime = 32;
>   	} else if (IS_CHAN_QUARTER_RATE(chan)) {
>   		eifs = 340;
> -		rx_lat *= 4;
> +		rx_lat *= 4 - 1;
That looks a bit weird. Did you mean to change it to *= 3 or was this 
just mistyped because you wanted to subtract one after the multiplication?

- Felix

Re: [PATCH 1/2] ath9k_hw: Fix rx latency of 11a mode

[Rajkumar Manoharan]

On Thu, Aug 25, 2011 at 05:32:10PM +0200, Felix Fietkau wrote:
> On 2011-08-25 4:45 PM, Rajkumar Manoharan wrote:
> >Rx latecy to start signal(usec) of 11a is 41 not 37 and
> >also corrected the rx delay in quarter rate.
> >
> >Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
> >---
> >  drivers/net/wireless/ath/ath9k/hw.c |    7 +++++--
> >  1 files changed, 5 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
> >index 88100cc..d4dce6b 100644
> >--- a/drivers/net/wireless/ath/ath9k/hw.c
> >+++ b/drivers/net/wireless/ath/ath9k/hw.c
> >@@ -974,7 +974,10 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
> >  	if (ah->misc_mode != 0)
> >  		REG_SET_BIT(ah, AR_PCU_MISC, ah->misc_mode);
> >
> >-	rx_lat = 37;
> >+	if (IS_CHAN_A_FAST_CLOCK(ah, chan))
> >+		rx_lat = 41;
> >+	else
> >+		rx_lat = 37;
> >  	tx_lat = 54;
> >
> >  	if (IS_CHAN_HALF_RATE(chan)) {
> >@@ -988,7 +991,7 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
> >  		sifstime = 32;
> >  	} else if (IS_CHAN_QUARTER_RATE(chan)) {
> >  		eifs = 340;
> >-		rx_lat *= 4;
> >+		rx_lat *= 4 - 1;
> That looks a bit weird. Did you mean to change it to *= 3 or was
> this just mistyped because you wanted to subtract one after the
> multiplication?
>
Oops.. it is rx_lat = (rx_lat * 4) - 1.

--
Rajkumar