Return-path: Received: from mailservices.uwaterloo.ca ([129.97.128.141]:39984 "EHLO minos.uwaterloo.ca" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1758517AbaJ3QUq (ORCPT ); Thu, 30 Oct 2014 12:20:46 -0400 Message-ID: <54526555.8020202@mailservices.uwaterloo.ca> (sfid-20141030_172053_935453_FF3A07C1) Date: Thu, 30 Oct 2014 12:20:37 -0400 From: Ali Abedi MIME-Version: 1.0 To: Adrian Chadd CC: ath9k-devel , "linux-wireless@vger.kernel.org" Subject: Re: strange MPDU loss pattern 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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: The paper mentioned that this happens when the client is mobile. But I confirm Adrian's observation . This problem happens even in stationary environments with dynamic channels (e.g., people moving in the vicinity of the AP/Client). Best, Ali On 14-10-30 12:11 PM, Adrian Chadd wrote: > 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