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 <[email protected]>
---
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
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<[email protected]>
> ---
> 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
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<[email protected]>
>> 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.
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<[email protected]>
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
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<[email protected]>
> >---
> > 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
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<[email protected]>
> 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
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 <[email protected]>
---
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
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<[email protected]>
> >> 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
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<[email protected]>
>> >> 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