From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier Marce Date: Wed, 2 Apr 2014 18:15:09 +0200 Subject: [ath9k-devel] Retry control & iwconfig In-Reply-To: <533BE03C.3050005@alcatel-lucent.com> References: <5333A700.8070108@gmail.com> <533711D9.4020407@gmail.com> <53394313.40306@ftw.at> <533BE03C.3050005@alcatel-lucent.com> Message-ID: <533C378D.90202@alcatel-lucent.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Hi, I found that it can work but depends on device used as STA. As I used special feature like noack on AP side only, I did not think that STA device would be so important in the setup. Then changing the STA makes it working. Not investigated yet why it did not work, I'll let the list know why mater (looks that some strange Block Ack policy was sent back by the STA toward the AP). Regards On 02/04/2014 12:02, Olivier Marce wrote: > Hi, > thanks Pradeep and Paul. > > I investigated on this. > But as this time, I'm unable to make a link working with no_ack, even if > I fix the rate. > > The environment is crowded, but not so much. With ACK (iw set > noack_map 0 to be sure), for a iperf 10 sec long test, I found only 43 > retry packets over 19k TCP packets. > > As soon as I set noack (iw set noack_map 9), the iperf test does > not work at all. I'm able to see only 2 packets coming from the iperf > client over 15 seconds of capture. > The same when fixing the rate (iwconfig rate 11M), the same with > 1M rate. > The capture done at the 2 ends (AP and STA) are consistent. > This is the same with ping, it does not work (98% packet loss) > > Other observations : > - the ACK are well transmitted in the 2 directions > - same behaviour if RTS/CTS on or off > > Did someone make a link with no_ack work ? In which condition ? > > Regards > > On 31/03/2014 12:27, Paul Fuxjaeger wrote: >> On 29.03.14 19:32, Pradeep Reddy wrote: >>> >>> I think, fixing the data rates to make it behave better. >> >> I think so too, maybe minstrel does something very unclever in context >> of NO_ACK being set (like sticking to a very high MCS). Or this is >> simply what we get when turning off (fast!) mac-layer retransmission in >> a busy environment and using TCP over that very leaky pipe then. >> >> -paul >> >> > -- Olivier Marc? Alcatel-Lucent Bell Labs France