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: Sat, 25 Oct 2014 11:28:53 -0400 [thread overview]
Message-ID: <544BC1B5.1040107@mailservices.uwaterloo.ca> (raw)
In-Reply-To: <CAJ-VmomYx1Dn5Oey1v4+8Yw7n0QkBiGKynFf_qNBD1JZb_Ra_A@mail.gmail.com>
Hi Adrian,
We have a high end spectrum analyzer. So we are sure there is no
background interference
We run our experiments in the 5 GHZ spectrum. The channel conditions can
still vary due to
the movement of the people in the vicinity of the experiment setup. We
select a rate that
experiences at least 20% error on average. Since if the error is 100% or
0% it's not interesting
for us.
My point is if the channel conditions change the distribution of failed
packets should be uniform.
The first and second half of the packets have the same chance to be
received successfully.
Thanks,
Ali
On 25/10/2014 11:19 AM, Adrian Chadd wrote:
> On 24 October 2014 13:42, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>> We don't use a rate adaptation at this moment (i.e., fixed rate) and the
>> setup
>> is stationary. So we expect to see relatively stable channel conditions.
>> Even if the channel
>> conditions change during the aggregated frame. The first half of the MPDUs
>> have the same chance of experiencing worse channel conditions.
> How do you /know/ you have stable channel conditions?
>
> There are a lot of things that could be going on inside the devices
> you're testing on. It doesn't have to be channel noise coming in an
> antenna. For example, your computer could be generating rapidly
> changing noise spurs from some clocking sources.
>
> Try firing up the spectral scan mode on the NIC and plot the data. See
> if there are any abnormal peaks going on over time.
>
> And a large / long A-MPDU could be measured in milliseconds of length.
> the original poster didn't say which rate(s) they are trying with and
> how much margin (SNR) the receiver is seeing. Pulling out EVM from the
> received A-MPDU frames would also be helpful.
>
> Thanks,
>
>
>
> -adrian
>
>
>
>
> -adrian
next prev parent reply other threads:[~2014-10-25 19:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 16:04 strange MPDU loss pattern Ali Abedi
2014-10-24 19:13 ` Adrian Chadd
2014-10-24 19:23 ` [ath9k-devel] " Kamran Nishat
2014-10-24 20:37 ` Krishna Chaitanya
2014-10-24 20:42 ` Ali Abedi
2014-10-25 15:19 ` Adrian Chadd
2014-10-25 15:28 ` Ali Abedi [this message]
2014-10-25 18:30 ` Adrian Chadd
[not found] ` <544C0995.8010507@mailservices.uwaterloo.ca>
[not found] ` <CAETUFS8iDDcrPwu_NCV4Ks9Mq6KUjqdujVyyZ5Y6om=14J+B9g@mail.gmail.com>
2014-10-27 12:05 ` [ath9k-devel] " Felix Fietkau
2014-10-29 20:34 ` Adrian Chadd
2014-10-30 15:48 ` Ali Abedi
2014-10-30 16:11 ` Adrian Chadd
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=544BC1B5.1040107@mailservices.uwaterloo.ca \
--to=a2abedi@uwaterloo.ca \
--cc=adrian@freebsd.org \
--cc=ath9k-devel@venema.h4ckr.net \
--cc=linux-wireless@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).