I recently updated a machine with AR9285 wireless from kernel version
3.0 to 3.2 and saw that wireless had become slow and unreliable. It
seems that the problem is extremely frequent CTS timeouts, which began
happening with commit adb5066 (ath9k_hw: do not apply the 2.4 ghz ack
timeout workaround to cts). Restoring the CTS timeout to the value prior
to this commit on top of 3.2 gets performance back to what it was with
3.0.
I don't have any other ath9k cards lying around, but various other cards
are working fine with this router. Any ideas what's wrong here?
Thanks,
Seth
On 2012-02-04 11:24 AM, Adrian Chadd wrote:
> hi,
>
> Felix, can we please revert that patch until we figure out why that's occuring?
>
> (And I now need to make sure I'm doing that in FreeBSD's HAL, as I'm
> pretty sure I've seen this with FreeBSD in the past.)
I don't think we need to revert the original change. I'll send this fix
as a patch for 3.3 soon, that makes the CTS timeout value match what
Atheros uses, so it should be safe.
- Felix
On 2012-02-02 3:15 PM, Martin Hundebøll wrote:
> Hi Felix,
>
> On 2012-02-02 13:35, Felix Fietkau wrote:
>> Please try this patch:
>>
>> --- a/drivers/net/wireless/ath/ath9k/hw.c
>> +++ b/drivers/net/wireless/ath/ath9k/hw.c
>> @@ -1061,13 +1061,16 @@ void ath9k_hw_init_global_settings(struc
>>
>> /*
>> * Workaround for early ACK timeouts, add an offset to match the
>> - * initval's 64us ack timeout value.
>> + * initval's 64us ack timeout value. Use 48us for the CTS timeout.
>> * This was initially only meant to work around an issue with delayed
>> * BA frames in some implementations, but it has been found to fix ACK
>> * timeout issues in other cases as well.
>> */
>> - if (conf->channel&& conf->channel->band == IEEE80211_BAND_2GHZ)
>> + if (conf->channel&& conf->channel->band == IEEE80211_BAND_2GHZ) {
>> acktimeout += 64 - sifstime - ah->slottime;
>> + ctstimeout += 48 - sifstime - ah->slottime;
>> + }
>> +
>>
>> ath9k_hw_set_sifs_time(ah, sifstime);
>> ath9k_hw_setslottime(ah, slottime);
>
> I have been seeing the same issues with the Atheros 9170 USB chipset
> using the carl9170 driver and firmware, where RST are transmitted
> repeatidly, even though a CTS-reply is seen on the air. I suspect the
> issue to be related to this one, but I am unable to locate any
> calculation or setting of CTS timeout in the driver or firmware.
>
> Can anyone point me in the right direction to tune the CTS timeout
> with the 9170 chip?
I think your carl9170 CTS issue is likely to be something else, since
AR9170 is using a completely different 802.11 MAC (Zydas design instead
of Atheros).
- Felix
On Thursday, February 02, 2012 22:38:43 Seth Forshee wrote:
> On Thu, Feb 02, 2012 at 01:35:22PM +0100, Felix Fietkau wrote:
> > On 2012-02-02 5:25 AM, Seth Forshee wrote:
> > > I recently updated a machine with AR9285 wireless from kernel version
> > > 3.0 to 3.2 and saw that wireless had become slow and unreliable. It
> > > seems that the problem is extremely frequent CTS timeouts, which began
> > > happening with commit adb5066 (ath9k_hw: do not apply the 2.4 ghz ack
> > > timeout workaround to cts). Restoring the CTS timeout to the value
> > > prior to this commit on top of 3.2 gets performance back to what it
> > > was with 3.0.
> > >
> > > I don't have any other ath9k cards lying around, but various other
> > > cards are working fine with this router. Any ideas what's wrong here?
> >
> > Please try this patch:
> >
> > --- a/drivers/net/wireless/ath/ath9k/hw.c
> > +++ b/drivers/net/wireless/ath/ath9k/hw.c
> > @@ -1061,13 +1061,16 @@ void ath9k_hw_init_global_settings(struc
> >
> > /*
> >
> > * Workaround for early ACK timeouts, add an offset to match the
> >
> > - * initval's 64us ack timeout value.
> > + * initval's 64us ack timeout value. Use 48us for the CTS timeout.
> >
> > * This was initially only meant to work around an issue with delayed
> > * BA frames in some implementations, but it has been found to fix
ACK
> > * timeout issues in other cases as well.
> > */
> >
> > - if (conf->channel && conf->channel->band == IEEE80211_BAND_2GHZ)
> > + if (conf->channel && conf->channel->band == IEEE80211_BAND_2GHZ) {
> >
> > acktimeout += 64 - sifstime - ah->slottime;
> >
> > + ctstimeout += 48 - sifstime - ah->slottime;
> > + }
> > +
> >
> > ath9k_hw_set_sifs_time(ah, sifstime);
> > ath9k_hw_setslottime(ah, slottime);
>
> The wireless seems to be working fine with this patch.
I second this - my rts/cts problems went away as well after applying this
patch.
Regards,
Marek
On Thu, Feb 02, 2012 at 01:35:22PM +0100, Felix Fietkau wrote:
> On 2012-02-02 5:25 AM, Seth Forshee wrote:
> > I recently updated a machine with AR9285 wireless from kernel version
> > 3.0 to 3.2 and saw that wireless had become slow and unreliable. It
> > seems that the problem is extremely frequent CTS timeouts, which began
> > happening with commit adb5066 (ath9k_hw: do not apply the 2.4 ghz ack
> > timeout workaround to cts). Restoring the CTS timeout to the value prior
> > to this commit on top of 3.2 gets performance back to what it was with
> > 3.0.
> >
> > I don't have any other ath9k cards lying around, but various other cards
> > are working fine with this router. Any ideas what's wrong here?
> Please try this patch:
>
> --- a/drivers/net/wireless/ath/ath9k/hw.c
> +++ b/drivers/net/wireless/ath/ath9k/hw.c
> @@ -1061,13 +1061,16 @@ void ath9k_hw_init_global_settings(struc
>
> /*
> * Workaround for early ACK timeouts, add an offset to match the
> - * initval's 64us ack timeout value.
> + * initval's 64us ack timeout value. Use 48us for the CTS timeout.
> * This was initially only meant to work around an issue with delayed
> * BA frames in some implementations, but it has been found to fix ACK
> * timeout issues in other cases as well.
> */
> - if (conf->channel && conf->channel->band == IEEE80211_BAND_2GHZ)
> + if (conf->channel && conf->channel->band == IEEE80211_BAND_2GHZ) {
> acktimeout += 64 - sifstime - ah->slottime;
> + ctstimeout += 48 - sifstime - ah->slottime;
> + }
> +
>
> ath9k_hw_set_sifs_time(ah, sifstime);
> ath9k_hw_setslottime(ah, slottime);
>
The wireless seems to be working fine with this patch.
On Thu, Feb 02, 2012 at 04:58:23PM +0530, Mohammed Shafi wrote:
> On Thu, Feb 2, 2012 at 9:55 AM, Seth Forshee <[email protected]> wrote:
> > I recently updated a machine with AR9285 wireless from kernel version
> > 3.0 to 3.2 and saw that wireless had become slow and unreliable. It
> > seems that the problem is extremely frequent CTS timeouts, which began
> > happening with commit adb5066 (ath9k_hw: do not apply the 2.4 ghz ack
> > timeout workaround to cts). Restoring the CTS timeout to the value prior
> > to this commit on top of 3.2 gets performance back to what it was with
> > 3.0.
>
> does the environment is a noisy one (or) clear one
It's relatively clear, there isn't much activity at all on the channel
besides this card and the AP. And like I said, other cards aren't having
this problem. Using wireshark I can also see that RTS frames are being
sent repeatedly even though the AP responds with CTS frames.
On 2012-02-02 5:25 AM, Seth Forshee wrote:
> I recently updated a machine with AR9285 wireless from kernel version
> 3.0 to 3.2 and saw that wireless had become slow and unreliable. It
> seems that the problem is extremely frequent CTS timeouts, which began
> happening with commit adb5066 (ath9k_hw: do not apply the 2.4 ghz ack
> timeout workaround to cts). Restoring the CTS timeout to the value prior
> to this commit on top of 3.2 gets performance back to what it was with
> 3.0.
>
> I don't have any other ath9k cards lying around, but various other cards
> are working fine with this router. Any ideas what's wrong here?
Please try this patch:
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1061,13 +1061,16 @@ void ath9k_hw_init_global_settings(struc
/*
* Workaround for early ACK timeouts, add an offset to match the
- * initval's 64us ack timeout value.
+ * initval's 64us ack timeout value. Use 48us for the CTS timeout.
* This was initially only meant to work around an issue with delayed
* BA frames in some implementations, but it has been found to fix ACK
* timeout issues in other cases as well.
*/
- if (conf->channel && conf->channel->band == IEEE80211_BAND_2GHZ)
+ if (conf->channel && conf->channel->band == IEEE80211_BAND_2GHZ) {
acktimeout += 64 - sifstime - ah->slottime;
+ ctstimeout += 48 - sifstime - ah->slottime;
+ }
+
ath9k_hw_set_sifs_time(ah, sifstime);
ath9k_hw_setslottime(ah, slottime);
hi,
Felix, can we please revert that patch until we figure out why that's occuring?
(And I now need to make sure I'm doing that in FreeBSD's HAL, as I'm
pretty sure I've seen this with FreeBSD in the past.)
Adrian
Hi Felix,
On 2012-02-02 13:35, Felix Fietkau wrote:
> Please try this patch:
>
> --- a/drivers/net/wireless/ath/ath9k/hw.c
> +++ b/drivers/net/wireless/ath/ath9k/hw.c
> @@ -1061,13 +1061,16 @@ void ath9k_hw_init_global_settings(struc
>
> /*
> * Workaround for early ACK timeouts, add an offset to match the
> - * initval's 64us ack timeout value.
> + * initval's 64us ack timeout value. Use 48us for the CTS timeout.
> * This was initially only meant to work around an issue with delayed
> * BA frames in some implementations, but it has been found to fix ACK
> * timeout issues in other cases as well.
> */
> - if (conf->channel&& conf->channel->band == IEEE80211_BAND_2GHZ)
> + if (conf->channel&& conf->channel->band == IEEE80211_BAND_2GHZ) {
> acktimeout += 64 - sifstime - ah->slottime;
> + ctstimeout += 48 - sifstime - ah->slottime;
> + }
> +
>
> ath9k_hw_set_sifs_time(ah, sifstime);
> ath9k_hw_setslottime(ah, slottime);
I have been seeing the same issues with the Atheros 9170 USB chipset using the carl9170 driver and firmware, where RST are transmitted repeatidly, even though a CTS-reply is seen on the air. I suspect the issue to be related to this one, but I am unable to locate any calculation or setting of CTS timeout in the driver or firmware.
Can anyone point me in the right direction to tune the CTS timeout with the 9170 chip?
Regards,
Martin Hundebøll
On Thu, Feb 2, 2012 at 9:55 AM, Seth Forshee <[email protected]> wrote:
> I recently updated a machine with AR9285 wireless from kernel version
> 3.0 to 3.2 and saw that wireless had become slow and unreliable. It
> seems that the problem is extremely frequent CTS timeouts, which began
> happening with commit adb5066 (ath9k_hw: do not apply the 2.4 ghz ack
> timeout workaround to cts). Restoring the CTS timeout to the value prior
> to this commit on top of 3.2 gets performance back to what it was with
> 3.0.
does the environment is a noisy one (or) clear one
>
> I don't have any other ath9k cards lying around, but various other cards
> are working fine with this router. Any ideas what's wrong here?
>
> Thanks,
> Seth
> --
> 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
--
shafi