All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ali Abedi <a2abedi@uwaterloo.ca>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] strange MPDU loss pattern
Date: Thu, 30 Oct 2014 12:20:37 -0400	[thread overview]
Message-ID: <54526555.8020202@mailservices.uwaterloo.ca> (raw)
In-Reply-To: <CAJ-VmonkWf5q445fR2PnsQarnA5Vuu4t4jNckU3-YUd+nbUZvQ@mail.gmail.com>

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 <a2abedi@uwaterloo.ca> 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

WARNING: multiple messages have this Message-ID (diff)
From: Ali Abedi <a2abedi@uwaterloo.ca>
To: Adrian Chadd <adrian@freebsd.org>
Cc: ath9k-devel <ath9k-devel@venema.h4ckr.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: strange MPDU loss pattern
Date: Thu, 30 Oct 2014 12:20:37 -0400	[thread overview]
Message-ID: <54526555.8020202@mailservices.uwaterloo.ca> (raw)
In-Reply-To: <CAJ-VmonkWf5q445fR2PnsQarnA5Vuu4t4jNckU3-YUd+nbUZvQ@mail.gmail.com>

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 <a2abedi@uwaterloo.ca> 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


  reply	other threads:[~2014-10-30 16:20 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 16:04 [ath9k-devel] strange MPDU loss pattern Ali Abedi
2014-10-24 16:04 ` Ali Abedi
2014-10-24 16:13 ` [ath9k-devel] " Kamran Nishat
2014-10-24 16:25   ` Ali Abedi
2014-10-24 19:13 ` Adrian Chadd
2014-10-24 19:13   ` Adrian Chadd
2014-10-24 19:23   ` [ath9k-devel] " Kamran Nishat
2014-10-24 19:23     ` Kamran Nishat
2014-10-24 20:37     ` Krishna Chaitanya
2014-10-24 20:37       ` Krishna Chaitanya
2014-10-24 20:42   ` Ali Abedi
2014-10-24 20:42     ` Ali Abedi
2014-10-25 15:19     ` [ath9k-devel] " Adrian Chadd
2014-10-25 15:19       ` Adrian Chadd
2014-10-25 15:28       ` [ath9k-devel] " Ali Abedi
2014-10-25 15:28         ` Ali Abedi
2014-10-25 18:30         ` [ath9k-devel] " Adrian Chadd
2014-10-25 18:30           ` Adrian Chadd
2014-10-25 20:35           ` [ath9k-devel] " Ali Abedi
     [not found]             ` <CAETUFS8iDDcrPwu_NCV4Ks9Mq6KUjqdujVyyZ5Y6om=14J+B9g@mail.gmail.com>
2014-10-27  1:50               ` Ali Abedi
2014-10-27 12:05               ` Felix Fietkau
2014-10-27 12:05                 ` Felix Fietkau
2014-10-29 20:34             ` Adrian Chadd
2014-10-29 20:34               ` Adrian Chadd
2014-10-30 15:48               ` [ath9k-devel] " Ali Abedi
2014-10-30 15:48                 ` Ali Abedi
2014-10-30 16:11                 ` [ath9k-devel] " Adrian Chadd
2014-10-30 16:11                   ` Adrian Chadd
2014-10-30 16:20                   ` Ali Abedi [this message]
2014-10-30 16:20                     ` Ali Abedi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54526555.8020202@mailservices.uwaterloo.ca \
    --to=a2abedi@uwaterloo.ca \
    --cc=ath9k-devel@lists.ath9k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.