Return-path: Received: from mail-wi0-f177.google.com ([209.85.212.177]:40852 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758111AbaJ3QL2 (ORCPT ); Thu, 30 Oct 2014 12:11:28 -0400 Received: by mail-wi0-f177.google.com with SMTP id ex7so7867906wid.4 for ; Thu, 30 Oct 2014 09:11:26 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <54525DD8.6080506@mailservices.uwaterloo.ca> References: <544A7871.7020005@mailservices.uwaterloo.ca> <544AB9B8.9050407@mailservices.uwaterloo.ca> <544BC1B5.1040107@mailservices.uwaterloo.ca> <544C0995.8010507@mailservices.uwaterloo.ca> <54525DD8.6080506@mailservices.uwaterloo.ca> Date: Thu, 30 Oct 2014 09:11:26 -0700 Message-ID: (sfid-20141030_171131_959319_D1930A25) Subject: Re: strange MPDU loss pattern From: Adrian Chadd To: Ali Abedi Cc: ath9k-devel , "linux-wireless@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 30 October 2014 08:48, Ali Abedi wrote: > Hi Adrian, > > > We observed that this can happen for any rate for some SNR values. > If the SNR is strong enough for the given MCS this won't happen. > But when the SNR approaches the transition region when > error rate starts to increase, this problem will be observed. > > So this can happen even for MCS0->MCS4 when the client is far from the AP > and specially when it's moving. Right. That's the missing useful information here. :) Yes, I'd expect this happens whilst the client is moving. The training stuff is all done on the beginning of the packet and channel conditions aren't adjusted during packet reception - only upon the next received packet. (FYI - I've seen a similar pattern, but when i stand between the AP / STA at > MCS13 and start waving my hands around. Just that slight change in channel conditions == the above failure.) So thanks for reminding us that we should take A-MPDU length into account in our rate control code. :) -adrian