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.ma...@alcatel-lucent.com> Subject: Re: [ath9k-devel] Retry control & iwconfig To:<ath9k-de...@venema.h4ckr.net> Message-ID:<5335a29e.3010...@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 _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
