[ath9k-devel] Retry control & iwconfig

[Pradeep Reddy <pradeepreddy.iit@gmail.com>]

Hi Olivier,

NO_ACK feature is meant for few special cases, like,
(i)when you want to inject certain packets (Injector), but doesn't bother whether it is delivered or not,
(ii) In QoS/11n case, where per packet ACK is disabled and Block ACK is enabled
(iii) For boradcast/multicast packets, for which ACK is not needed, For Ex Beacons

As you are aware the purpose of ACK in 802.11 Std is to ensure the data packet is delivered without any errors to intended destination, due to uncertainty nature of Wireless Medium.

In your case, NO_ACK is set, but Rate control algorithm is still decides the rate based on Tx stats and sets number of retries. But since NO_ACK bit is set, h/w won't wait for ACK and doesn't ensure the error-free delivery of data packets to target.

With NO_ACK set also, still the STA follows the CSMA/CA protocol, doesn't violate any protocol timings. I think, your env might be busy with lot of WLAN traffic, so that even with higher signal strengths the packets might not be making till destination as error-free. Is that Correct ?

I think, fixing the data rates to make it behave better.

Let me know how it goes.

Regards
Pradeep

Date: Fri, 28 Mar 2014 17:26:06 +0100
From: Olivier Marce<Olivier.Marce@alcatel-lucent.com>
Subject: Re: [ath9k-devel] Retry control & iwconfig
To:<ath9k-devel@venema.h4ckr.net>
Message-ID:<5335A29E.3010209@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed

Hi Pradeep,
thanks, this helped me a lot.
It pointed me out to iw command "set noack_map" that is made to set
IEEE80211_TX_CTL_NO_ACK flag, and that I did not consider before.

I then used "iw <dev> set noack_map 9" to avoid waiting for ACK  and to
avoid retries by <dev>.
What I expected was to see almost no difference with noack when the link
conditions are good (i.e. high RSSI level).
But this is not the case, with noack set, the data transfer is almost
not possible (I used iperf, and it even does not complete its test, 95
to 98% lost packet with ping).

What is the reason for this ? Does the NO_ACK bit has an additional
impact on the device behaviour like not respecting the requested delays
on the air, or whatever ?
Any idea ?

Thanks.

Olivier.

On 27/03/2014 05:20, Pradeep Reddy wrote:

> Hi Marc,
>
> You can set NO_ACK bit in Tx descriptor of each packet to indicate the
> hardware to not to wait for ACK, which in turn avoids retries for that
> particular packet.
>
> If you set IEEE80211_TX_CTL_NO_ACK flag in tx_ctl information, ath9k
> layer will take care of setting the Tx descriptor flag ATH9K_TXDESC_NOACK.
>
> Regards
> Pradeep