[ath9k-devel] strange MPDU loss pattern

[ath9k-devel] strange MPDU loss pattern

[Ali Abedi]

Hello,

We study the effects of 802.11n frame aggregation on throughput. We 
noticed a
strange pattern in the MPDU loss within an aggregated frame. It seems 
that the
second half of the MPDUs (those with higher sequence numbers) in an 
aggregated frame
are more likely to be lost. Is this a known fact or is there any 
explanation for it?

For example if 32 frames are aggregated with sequence numbers 100 to 131.
Frames with sequence numbers 100-115 are more likely to be received 
correctly
than 116-131.


Best,
Ali

strange MPDU loss pattern

[Ali Abedi]

Hello,

We study the effects of 802.11n frame aggregation on throughput. We 
noticed a
strange pattern in the MPDU loss within an aggregated frame. It seems 
that the
second half of the MPDUs (those with higher sequence numbers) in an 
aggregated frame
are more likely to be lost. Is this a known fact or is there any 
explanation for it?

For example if 32 frames are aggregated with sequence numbers 100 to 131.
Frames with sequence numbers 100-115 are more likely to be received 
correctly
than 116-131.


Best,
Ali

[ath9k-devel] strange MPDU loss pattern

[Kamran Nishat]

How did u determine that? only by looking at the Bitmaps in BlockAcks?

On Fri, Oct 24, 2014 at 9:04 PM, Ali Abedi <a2abedi@uwaterloo.ca> wrote:

> Hello,
>
> We study the effects of 802.11n frame aggregation on throughput. We
> noticed a
> strange pattern in the MPDU loss within an aggregated frame. It seems
> that the
> second half of the MPDUs (those with higher sequence numbers) in an
> aggregated frame
> are more likely to be lost. Is this a known fact or is there any
> explanation for it?
>
> For example if 32 frames are aggregated with sequence numbers 100 to 131.
> Frames with sequence numbers 100-115 are more likely to be received
> correctly
> than 116-131.
>
>
> Best,
> Ali
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20141024/4cfdcd36/attachment-0001.htm 

[ath9k-devel] strange MPDU loss pattern

[Ali Abedi]

Hi,

Yes we look at the BA bitmap and also too we have printks in the driver 
that
tells us what happened to the MPDUs in an aggregated frame.

Thanks,
Ali


On 24/10/2014 12:13 PM, Kamran Nishat wrote:
> How did u determine that? only by looking at the Bitmaps in BlockAcks?
>
> On Fri, Oct 24, 2014 at 9:04 PM, Ali Abedi <a2abedi@uwaterloo.ca 
> <mailto:a2abedi@uwaterloo.ca>> wrote:
>
>     Hello,
>
>     We study the effects of 802.11n frame aggregation on throughput. We
>     noticed a
>     strange pattern in the MPDU loss within an aggregated frame. It seems
>     that the
>     second half of the MPDUs (those with higher sequence numbers) in an
>     aggregated frame
>     are more likely to be lost. Is this a known fact or is there any
>     explanation for it?
>
>     For example if 32 frames are aggregated with sequence numbers 100
>     to 131.
>     Frames with sequence numbers 100-115 are more likely to be received
>     correctly
>     than 116-131.
>
>
>     Best,
>     Ali
>     _______________________________________________
>     ath9k-devel mailing list
>     ath9k-devel at lists.ath9k.org <mailto:ath9k-devel@lists.ath9k.org>
>     https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20141024/fca5fb5f/attachment.htm 

[ath9k-devel] strange MPDU loss pattern

[Adrian Chadd]

It's not completely unsurprising - the initial channel estimate and
such is done at the beginning of each packet and stays constant. So if
there's some varying channel conditions that change that during the
duration of a packet, the tail end is going to end up having less SNR
and may end up getting more errors.


-adrian

On 24 October 2014 09:04, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> Hello,
>
> We study the effects of 802.11n frame aggregation on throughput. We noticed
> a
> strange pattern in the MPDU loss within an aggregated frame. It seems that
> the
> second half of the MPDUs (those with higher sequence numbers) in an
> aggregated frame
> are more likely to be lost. Is this a known fact or is there any explanation
> for it?
>
> For example if 32 frames are aggregated with sequence numbers 100 to 131.
> Frames with sequence numbers 100-115 are more likely to be received
> correctly
> than 116-131.
>
>
> Best,
> Ali
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange MPDU loss pattern

[Adrian Chadd]

It's not completely unsurprising - the initial channel estimate and
such is done at the beginning of each packet and stays constant. So if
there's some varying channel conditions that change that during the
duration of a packet, the tail end is going to end up having less SNR
and may end up getting more errors.


-adrian

On 24 October 2014 09:04, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> Hello,
>
> We study the effects of 802.11n frame aggregation on throughput. We noticed
> a
> strange pattern in the MPDU loss within an aggregated frame. It seems that
> the
> second half of the MPDUs (those with higher sequence numbers) in an
> aggregated frame
> are more likely to be lost. Is this a known fact or is there any explanation
> for it?
>
> For example if 32 frames are aggregated with sequence numbers 100 to 131.
> Frames with sequence numbers 100-115 are more likely to be received
> correctly
> than 116-131.
>
>
> Best,
> Ali
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ath9k-devel] strange MPDU loss pattern

[Kamran Nishat]

But for this channel conditions should be changing at the scale of 100
micro secs consistently.

On Sat, Oct 25, 2014 at 12:13 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> It's not completely unsurprising - the initial channel estimate and
> such is done at the beginning of each packet and stays constant. So if
> there's some varying channel conditions that change that during the
> duration of a packet, the tail end is going to end up having less SNR
> and may end up getting more errors.
>
>
> -adrian
>
> On 24 October 2014 09:04, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>> Hello,
>>
>> We study the effects of 802.11n frame aggregation on throughput. We noticed
>> a
>> strange pattern in the MPDU loss within an aggregated frame. It seems that
>> the
>> second half of the MPDUs (those with higher sequence numbers) in an
>> aggregated frame
>> are more likely to be lost. Is this a known fact or is there any explanation
>> for it?
>>
>> For example if 32 frames are aggregated with sequence numbers 100 to 131.
>> Frames with sequence numbers 100-115 are more likely to be received
>> correctly
>> than 116-131.
>>
>>
>> Best,
>> Ali
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] strange MPDU loss pattern

[Kamran Nishat]

But for this channel conditions should be changing at the scale of 100
micro secs consistently.

On Sat, Oct 25, 2014 at 12:13 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> It's not completely unsurprising - the initial channel estimate and
> such is done at the beginning of each packet and stays constant. So if
> there's some varying channel conditions that change that during the
> duration of a packet, the tail end is going to end up having less SNR
> and may end up getting more errors.
>
>
> -adrian
>
> On 24 October 2014 09:04, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>> Hello,
>>
>> We study the effects of 802.11n frame aggregation on throughput. We noticed
>> a
>> strange pattern in the MPDU loss within an aggregated frame. It seems that
>> the
>> second half of the MPDUs (those with higher sequence numbers) in an
>> aggregated frame
>> are more likely to be lost. Is this a known fact or is there any explanation
>> for it?
>>
>> For example if 32 frames are aggregated with sequence numbers 100 to 131.
>> Frames with sequence numbers 100-115 are more likely to be received
>> correctly
>> than 116-131.
>>
>>
>> Best,
>> Ali
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] strange MPDU loss pattern

[Krishna Chaitanya]

On Sat, Oct 25, 2014 at 12:53 AM, Kamran Nishat <kamran.nishat@gmail.com> wrote:
>
> But for this channel conditions should be changing at the scale of 100
> micro secs consistently.
>
> On Sat, Oct 25, 2014 at 12:13 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> > It's not completely unsurprising - the initial channel estimate and
> > such is done at the beginning of each packet and stays constant. So if
> > there's some varying channel conditions that change that during the
> > duration of a packet, the tail end is going to end up having less SNR
> > and may end up getting more errors.
> >
> >
> > -adrian
> >
> > On 24 October 2014 09:04, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> >> Hello,
> >>
> >> We study the effects of 802.11n frame aggregation on throughput. We noticed
> >> a
> >> strange pattern in the MPDU loss within an aggregated frame. It seems that
> >> the
> >> second half of the MPDUs (those with higher sequence numbers) in an
> >> aggregated frame
> >> are more likely to be lost. Is this a known fact or is there any explanation
> >> for it?
> >>
> >> For example if 32 frames are aggregated with sequence numbers 100 to 131.
> >> Frames with sequence numbers 100-115 are more likely to be received
> >> correctly
> >> than 116-131.
> >>
> There is no known limitation/explanation for losing 2nd half of MPDU's in an A-MPDU
*every time (most likely)*. This might specific to the case, can you
share a capture?

Re: [ath9k-devel] strange MPDU loss pattern

[Krishna Chaitanya]

On Sat, Oct 25, 2014 at 12:53 AM, Kamran Nishat <kamran.nishat@gmail.com> wrote:
>
> But for this channel conditions should be changing at the scale of 100
> micro secs consistently.
>
> On Sat, Oct 25, 2014 at 12:13 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> > It's not completely unsurprising - the initial channel estimate and
> > such is done at the beginning of each packet and stays constant. So if
> > there's some varying channel conditions that change that during the
> > duration of a packet, the tail end is going to end up having less SNR
> > and may end up getting more errors.
> >
> >
> > -adrian
> >
> > On 24 October 2014 09:04, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> >> Hello,
> >>
> >> We study the effects of 802.11n frame aggregation on throughput. We noticed
> >> a
> >> strange pattern in the MPDU loss within an aggregated frame. It seems that
> >> the
> >> second half of the MPDUs (those with higher sequence numbers) in an
> >> aggregated frame
> >> are more likely to be lost. Is this a known fact or is there any explanation
> >> for it?
> >>
> >> For example if 32 frames are aggregated with sequence numbers 100 to 131.
> >> Frames with sequence numbers 100-115 are more likely to be received
> >> correctly
> >> than 116-131.
> >>
> There is no known limitation/explanation for losing 2nd half of MPDU's in an A-MPDU
*every time (most likely)*. This might specific to the case, can you
share a capture?

[ath9k-devel] strange MPDU loss pattern

[Ali Abedi]

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.

Thank,
Ali


On 14-10-24 03:13 PM, Adrian Chadd wrote:
> It's not completely unsurprising - the initial channel estimate and
> such is done at the beginning of each packet and stays constant. So if
> there's some varying channel conditions that change that during the
> duration of a packet, the tail end is going to end up having less SNR
> and may end up getting more errors.
>
>
> -adrian
>
> On 24 October 2014 09:04, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>> Hello,
>>
>> We study the effects of 802.11n frame aggregation on throughput. We noticed
>> a
>> strange pattern in the MPDU loss within an aggregated frame. It seems that
>> the
>> second half of the MPDUs (those with higher sequence numbers) in an
>> aggregated frame
>> are more likely to be lost. Is this a known fact or is there any explanation
>> for it?
>>
>> For example if 32 frames are aggregated with sequence numbers 100 to 131.
>> Frames with sequence numbers 100-115 are more likely to be received
>> correctly
>> than 116-131.
>>
>>
>> Best,
>> Ali
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange MPDU loss pattern

[Ali Abedi]

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.

Thank,
Ali


On 14-10-24 03:13 PM, Adrian Chadd wrote:
> It's not completely unsurprising - the initial channel estimate and
> such is done at the beginning of each packet and stays constant. So if
> there's some varying channel conditions that change that during the
> duration of a packet, the tail end is going to end up having less SNR
> and may end up getting more errors.
>
>
> -adrian
>
> On 24 October 2014 09:04, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>> Hello,
>>
>> We study the effects of 802.11n frame aggregation on throughput. We noticed
>> a
>> strange pattern in the MPDU loss within an aggregated frame. It seems that
>> the
>> second half of the MPDUs (those with higher sequence numbers) in an
>> aggregated frame
>> are more likely to be lost. Is this a known fact or is there any explanation
>> for it?
>>
>> For example if 32 frames are aggregated with sequence numbers 100 to 131.
>> Frames with sequence numbers 100-115 are more likely to be received
>> correctly
>> than 116-131.
>>
>>
>> Best,
>> Ali
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ath9k-devel] strange MPDU loss pattern

[Adrian Chadd]

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

Re: strange MPDU loss pattern

[Adrian Chadd]

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

[ath9k-devel] strange MPDU loss pattern

[Ali Abedi]

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

Re: strange MPDU loss pattern

[Ali Abedi]

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

[ath9k-devel] strange MPDU loss pattern

[Adrian Chadd]

On 25 October 2014 08:28, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> 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.

Here's a little story.

My first wifi contract had me spend months trying to figure out why an
AP was losing its mind. It'd get stuck in a "stuck beacon" loop and
only a hard powercycle of /all/ of the access points in an area would
clear it.

It turned out that the PCB design had some non-grounded /
non-populated tracks that just "happened" to form a 2GHz resonator.
Once we grounded those tracks, the APs started behaving themselves.

The company in question spent months with high end spectrum analysis
kit in the lab (where it never happened) and underground (where it did
happen.) It's only after they stuck the spectrum analyser probe
_inside the access point_ right up close to the NIC did they see it.

Here's the spectrum analyser traces. You can see the peak.

http://www.creative.net.au/ath/

So, weirder crap has happened.

Which NICs and which MCS rates are you using?



-adrian

Re: strange MPDU loss pattern

[Adrian Chadd]

On 25 October 2014 08:28, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> 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.

Here's a little story.

My first wifi contract had me spend months trying to figure out why an
AP was losing its mind. It'd get stuck in a "stuck beacon" loop and
only a hard powercycle of /all/ of the access points in an area would
clear it.

It turned out that the PCB design had some non-grounded /
non-populated tracks that just "happened" to form a 2GHz resonator.
Once we grounded those tracks, the APs started behaving themselves.

The company in question spent months with high end spectrum analysis
kit in the lab (where it never happened) and underground (where it did
happen.) It's only after they stuck the spectrum analyser probe
_inside the access point_ right up close to the NIC did they see it.

Here's the spectrum analyser traces. You can see the peak.

http://www.creative.net.au/ath/

So, weirder crap has happened.

Which NICs and which MCS rates are you using?



-adrian

[ath9k-devel] strange MPDU loss pattern

[Ali Abedi]

Thank you for sharing the story.
Even if I consider interference as a possibility, still I can't justify 
the higher
chance of frame loss in the second half of the aggregate frame.

We use

PCI-express 3 antenna dual band cards
product: AR93xx Wireless Network Adapter
and/or
Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop

we also tried TP-LINK TL-WDN4200 N900 
<http://www.google.ca/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0CAUQjhw&url=http%3A%2F%2Fwww.newegg.com%2FProduct%2FProduct.aspx%3FItem%3DN82E16833704195&ei=AglMVOw-w8TxAfW4gZAH&bvm=bv.77880786,d.b2U&psig=AFQjCNFYng4rfQG-HxRTr2hrjqAkrhLpTQ&ust=1414355559112616> 
as the receiver.

However we see the same results.
we mostly use MCS 20-23, sgi = 0, 20 MHz channels.

The loss pattern is something like this
(each line is an imaginary aggregated frame and each bit is the fate of 
the MPDU)

11111111111100011000000000000
11111110001101011010000000000
11111000000000000000000000000
11111111111010100000000000000
11111100101010000000000000000

The interesting part is that with the start of the next frame error rate 
goes down initially
then it goes up again in the second portion of the packet.

Best,
Ali




On 25/10/2014 2:30 PM, Adrian Chadd wrote:
> On 25 October 2014 08:28, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>> 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.
> Here's a little story.
>
> My first wifi contract had me spend months trying to figure out why an
> AP was losing its mind. It'd get stuck in a "stuck beacon" loop and
> only a hard powercycle of /all/ of the access points in an area would
> clear it.
>
> It turned out that the PCB design had some non-grounded /
> non-populated tracks that just "happened" to form a 2GHz resonator.
> Once we grounded those tracks, the APs started behaving themselves.
>
> The company in question spent months with high end spectrum analysis
> kit in the lab (where it never happened) and underground (where it did
> happen.) It's only after they stuck the spectrum analyser probe
> _inside the access point_ right up close to the NIC did they see it.
>
> Here's the spectrum analyser traces. You can see the peak.
>
> http://www.creative.net.au/ath/
>
> So, weirder crap has happened.
>
> Which NICs and which MCS rates are you using?
>
>
>
> -adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20141025/f49b2439/attachment-0001.htm 

[ath9k-devel] strange MPDU loss pattern

[Ali Abedi]

Dear Seongho ,

Thank you for your reply. Very good paper! I know about this conference. 
I am a Ph.D. student
in computer science too.

I am very certain that what we observe is what you found in this paper. 
I CC this to the mailing list so that others find out about this 
problem.  Your observation explains why with the start of a new 
aggregated frame, error rate decreases again.

Best,
Ali

On 26/10/2014 12:14 AM, Seongho Byeon wrote:
>
> Hi, I am Ph.d. student in Seoul National University , Korea.
> Recently, we have dealt with the problem you observe, and we published 
> a paper into CoNEXT 2014 which is a major conference in our field.
>
> Title of the paper 'MoFa: Mobility-aware Frame Aggregation in WiFi 
> networks'.
> You can download it a site below.
> http://www.mwnl.snu.ac.kr/~schoi/publication/Conferences/14-CONEXT-BYEON.pdf 
> <http://www.mwnl.snu.ac.kr/%7Eschoi/publication/Conferences/14-CONEXT-BYEON.pdf>
> If you have a question please contact me anytime.
>
> Best regards,
> Seongho Byeon.
>
> Thank you for sharing the story.
> Even if I consider interference as a possibility, still I can't 
> justify the higher
> chance of frame loss in the second half of the aggregate frame.
>
> We use
>
> PCI-express 3 antenna dual band cards
> product: AR93xx Wireless Network Adapter
> and/or
> Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop
>
> we also tried TP-LINK TL-WDN4200 N900as the receiver.
>
> However we see the same results.
> we mostly use MCS 20-23, sgi = 0, 20 MHz channels.
>
> The loss pattern is something like this
> (each line is an imaginary aggregated frame and each bit is the fate 
> of the MPDU)
>
> 11111111111100011000000000000
> 11111110001101011010000000000
> 11111000000000000000000000000
> 11111111111010100000000000000
> 11111100101010000000000000000
>
> The interesting part is that with the start of the next frame error 
> rate goes down initially
> then it goes up again in the second portion of the packet.
>
> Best,
> Ali
>
>
> On 25/10/2014 2:30 PM, Adrian Chadd wrote:
>
>     On 25 October 2014 08:28, Ali Abedi<a2abedi@uwaterloo.ca>
>     <mailto:a2abedi@uwaterloo.ca>wrote:
>
>         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.
>
>     Here's a little story. My first wifi contract had me spend months
>     trying to figure out why an AP was losing its mind. It'd get stuck
>     in a "stuck beacon" loop and only a hard powercycle of /all/ of
>     the access points in an area would clear it. It turned out that
>     the PCB design had some non-grounded / non-populated tracks that
>     just "happened" to form a 2GHz resonator. Once we grounded those
>     tracks, the APs started behaving themselves. The company in
>     question spent months with high end spectrum analysis kit in the
>     lab (where it never happened) and underground (where it did
>     happen.) It's only after they stuck the spectrum analyser probe
>     _inside the access point_ right up close to the NIC did they see
>     it. Here's the spectrum analyser traces. You can see the
>     peak.http://www.creative.net.au/ath/So, weirder crap has happened.
>     Which NICs and which MCS rates are you using? -adrian
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org <mailto:ath9k-devel@lists.ath9k.org>
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20141026/af6c7813/attachment.htm 

[ath9k-devel] strange MPDU loss pattern

[Felix Fietkau]

Hi Seongho,

that paper looks quite interesting.
Are you planning to publish code/patches for your implementation as well?
It would be nice to have dynamic A-MPDU limiting integrated in minstrel_ht.

Thanks,

- Felix

On 26/10/2014 12:14 AM, Seongho Byeon wrote:
>
> Hi, I am Ph.d. student in Seoul National University , Korea.
> Recently, we have dealt with the problem you observe, and we published
> a paper into CoNEXT 2014 which is a major conference in our field.
>
> Title of the paper 'MoFa: Mobility-aware Frame Aggregation in WiFi
> networks'.
> You can download it a site below.
> http://www.mwnl.snu.ac.kr/~schoi/publication/Conferences/14-CONEXT-BYEON.pdf
> <http://www.mwnl.snu.ac.kr/%7Eschoi/publication/Conferences/14-CONEXT-BYEON.pdf>
> If you have a question please contact me anytime.
>
> Best regards,
> Seongho Byeon.
>
> Thank you for sharing the story.
> Even if I consider interference as a possibility, still I can't
> justify the higher
> chance of frame loss in the second half of the aggregate frame.
>
> We use
>
> PCI-express 3 antenna dual band cards
> product: AR93xx Wireless Network Adapter
> and/or
> Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop
>
> we also tried TP-LINK TL-WDN4200 N900as the receiver.
>
> However we see the same results.
> we mostly use MCS 20-23, sgi = 0, 20 MHz channels.
>
> The loss pattern is something like this
> (each line is an imaginary aggregated frame and each bit is the fate
> of the MPDU)
>
> 11111111111100011000000000000
> 11111110001101011010000000000
> 11111000000000000000000000000
> 11111111111010100000000000000
> 11111100101010000000000000000
>
> The interesting part is that with the start of the next frame error
> rate goes down initially
> then it goes up again in the second portion of the packet.
>
> Best,
> Ali
>
>
> On 25/10/2014 2:30 PM, Adrian Chadd wrote:
>
>     On 25 October 2014 08:28, Ali Abedi<a2abedi@uwaterloo.ca>
>     <mailto:a2abedi@uwaterloo.ca>wrote:
>
>         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.
>
>     Here's a little story. My first wifi contract had me spend months
>     trying to figure out why an AP was losing its mind. It'd get stuck
>     in a "stuck beacon" loop and only a hard powercycle of /all/ of
>     the access points in an area would clear it. It turned out that
>     the PCB design had some non-grounded / non-populated tracks that
>     just "happened" to form a 2GHz resonator. Once we grounded those
>     tracks, the APs started behaving themselves. The company in
>     question spent months with high end spectrum analysis kit in the
>     lab (where it never happened) and underground (where it did
>     happen.) It's only after they stuck the spectrum analyser probe
>     _inside the access point_ right up close to the NIC did they see
>     it. Here's the spectrum analyser traces. You can see the
>     peak.http://www.creative.net.au/ath/So, weirder crap has happened.
>     Which NICs and which MCS rates are you using? -adrian
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org <mailto:ath9k-devel@lists.ath9k.org>
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

Re: [ath9k-devel] strange MPDU loss pattern

[Felix Fietkau]

Hi Seongho,

that paper looks quite interesting.
Are you planning to publish code/patches for your implementation as well?
It would be nice to have dynamic A-MPDU limiting integrated in minstrel_ht.

Thanks,

- Felix

On 26/10/2014 12:14 AM, Seongho Byeon wrote:
>
> Hi, I am Ph.d. student in Seoul National University , Korea.
> Recently, we have dealt with the problem you observe, and we published
> a paper into CoNEXT 2014 which is a major conference in our field.
>
> Title of the paper 'MoFa: Mobility-aware Frame Aggregation in WiFi
> networks'.
> You can download it a site below.
> http://www.mwnl.snu.ac.kr/~schoi/publication/Conferences/14-CONEXT-BYEON.pdf
> <http://www.mwnl.snu.ac.kr/%7Eschoi/publication/Conferences/14-CONEXT-BYEON.pdf>
> If you have a question please contact me anytime.
>
> Best regards,
> Seongho Byeon.
>
> Thank you for sharing the story.
> Even if I consider interference as a possibility, still I can't
> justify the higher
> chance of frame loss in the second half of the aggregate frame.
>
> We use
>
> PCI-express 3 antenna dual band cards
> product: AR93xx Wireless Network Adapter
> and/or
> Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop
>
> we also tried TP-LINK TL-WDN4200 N900as the receiver.
>
> However we see the same results.
> we mostly use MCS 20-23, sgi = 0, 20 MHz channels.
>
> The loss pattern is something like this
> (each line is an imaginary aggregated frame and each bit is the fate
> of the MPDU)
>
> 11111111111100011000000000000
> 11111110001101011010000000000
> 11111000000000000000000000000
> 11111111111010100000000000000
> 11111100101010000000000000000
>
> The interesting part is that with the start of the next frame error
> rate goes down initially
> then it goes up again in the second portion of the packet.
>
> Best,
> Ali
>
>
> On 25/10/2014 2:30 PM, Adrian Chadd wrote:
>
>     On 25 October 2014 08:28, Ali Abedi<a2abedi@uwaterloo.ca>
>     <mailto:a2abedi@uwaterloo.ca>wrote:
>
>         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.
>
>     Here's a little story. My first wifi contract had me spend months
>     trying to figure out why an AP was losing its mind. It'd get stuck
>     in a "stuck beacon" loop and only a hard powercycle of /all/ of
>     the access points in an area would clear it. It turned out that
>     the PCB design had some non-grounded / non-populated tracks that
>     just "happened" to form a 2GHz resonator. Once we grounded those
>     tracks, the APs started behaving themselves. The company in
>     question spent months with high end spectrum analysis kit in the
>     lab (where it never happened) and underground (where it did
>     happen.) It's only after they stuck the spectrum analyser probe
>     _inside the access point_ right up close to the NIC did they see
>     it. Here's the spectrum analyser traces. You can see the
>     peak.http://www.creative.net.au/ath/So, weirder crap has happened.
>     Which NICs and which MCS rates are you using? -adrian
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org <mailto:ath9k-devel@lists.ath9k.org>
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] strange MPDU loss pattern

[Adrian Chadd]

Just finally -

MCS20 -> MCS23 are very sensitive to changing channel anything. See if
you can find or make some required SNR curves for each MCS rate.

So although it doesn't surprise me to find this is happening, it's
very cute that someone's gone and done the work of figuring out how to
improve the rate control algorithm to take it into account. I'm kinda
thinking about how to do that with FreeBSD right now.

Do you get the same pattern on say, MCS0->MCS4 over a 4ms long aggregate frame?


-adrian

On 25 October 2014 13:35, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> Thank you for sharing the story.
> Even if I consider interference as a possibility, still I can't justify the
> higher
> chance of frame loss in the second half of the aggregate frame.
>
> We use
>
> PCI-express 3 antenna dual band cards
> product: AR93xx Wireless Network Adapter
> and/or
> Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop
>
> we also tried TP-LINK TL-WDN4200 N900 as the receiver.
>
> However we see the same results.
> we mostly use MCS 20-23, sgi = 0, 20 MHz channels.
>
> The loss pattern is something like this
> (each line is an imaginary aggregated frame and each bit is the fate of the
> MPDU)
>
> 11111111111100011000000000000
> 11111110001101011010000000000
> 11111000000000000000000000000
> 11111111111010100000000000000
> 11111100101010000000000000000
>
> The interesting part is that with the start of the next frame error rate
> goes down initially
> then it goes up again in the second portion of the packet.
>
> Best,
> Ali
>
>
>
>
>
> On 25/10/2014 2:30 PM, Adrian Chadd wrote:
>
> On 25 October 2014 08:28, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>
> 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.
>
> Here's a little story.
>
> My first wifi contract had me spend months trying to figure out why an
> AP was losing its mind. It'd get stuck in a "stuck beacon" loop and
> only a hard powercycle of /all/ of the access points in an area would
> clear it.
>
> It turned out that the PCB design had some non-grounded /
> non-populated tracks that just "happened" to form a 2GHz resonator.
> Once we grounded those tracks, the APs started behaving themselves.
>
> The company in question spent months with high end spectrum analysis
> kit in the lab (where it never happened) and underground (where it did
> happen.) It's only after they stuck the spectrum analyser probe
> _inside the access point_ right up close to the NIC did they see it.
>
> Here's the spectrum analyser traces. You can see the peak.
>
> http://www.creative.net.au/ath/
>
> So, weirder crap has happened.
>
> Which NICs and which MCS rates are you using?
>
>
>
> -adrian
>
>

Re: strange MPDU loss pattern

[Adrian Chadd]

Just finally -

MCS20 -> MCS23 are very sensitive to changing channel anything. See if
you can find or make some required SNR curves for each MCS rate.

So although it doesn't surprise me to find this is happening, it's
very cute that someone's gone and done the work of figuring out how to
improve the rate control algorithm to take it into account. I'm kinda
thinking about how to do that with FreeBSD right now.

Do you get the same pattern on say, MCS0->MCS4 over a 4ms long aggregate frame?


-adrian

On 25 October 2014 13:35, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> Thank you for sharing the story.
> Even if I consider interference as a possibility, still I can't justify the
> higher
> chance of frame loss in the second half of the aggregate frame.
>
> We use
>
> PCI-express 3 antenna dual band cards
> product: AR93xx Wireless Network Adapter
> and/or
> Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop
>
> we also tried TP-LINK TL-WDN4200 N900 as the receiver.
>
> However we see the same results.
> we mostly use MCS 20-23, sgi = 0, 20 MHz channels.
>
> The loss pattern is something like this
> (each line is an imaginary aggregated frame and each bit is the fate of the
> MPDU)
>
> 11111111111100011000000000000
> 11111110001101011010000000000
> 11111000000000000000000000000
> 11111111111010100000000000000
> 11111100101010000000000000000
>
> The interesting part is that with the start of the next frame error rate
> goes down initially
> then it goes up again in the second portion of the packet.
>
> Best,
> Ali
>
>
>
>
>
> On 25/10/2014 2:30 PM, Adrian Chadd wrote:
>
> On 25 October 2014 08:28, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>
> 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.
>
> Here's a little story.
>
> My first wifi contract had me spend months trying to figure out why an
> AP was losing its mind. It'd get stuck in a "stuck beacon" loop and
> only a hard powercycle of /all/ of the access points in an area would
> clear it.
>
> It turned out that the PCB design had some non-grounded /
> non-populated tracks that just "happened" to form a 2GHz resonator.
> Once we grounded those tracks, the APs started behaving themselves.
>
> The company in question spent months with high end spectrum analysis
> kit in the lab (where it never happened) and underground (where it did
> happen.) It's only after they stuck the spectrum analyser probe
> _inside the access point_ right up close to the NIC did they see it.
>
> Here's the spectrum analyser traces. You can see the peak.
>
> http://www.creative.net.au/ath/
>
> So, weirder crap has happened.
>
> Which NICs and which MCS rates are you using?
>
>
>
> -adrian
>
>

[ath9k-devel] strange MPDU loss pattern

[Ali Abedi]

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.

Thanks,
Ali


On 14-10-29 04:34 PM, Adrian Chadd wrote:
> Just finally -
>
> MCS20 -> MCS23 are very sensitive to changing channel anything. See if
> you can find or make some required SNR curves for each MCS rate.
>
> So although it doesn't surprise me to find this is happening, it's
> very cute that someone's gone and done the work of figuring out how to
> improve the rate control algorithm to take it into account. I'm kinda
> thinking about how to do that with FreeBSD right now.
>
> Do you get the same pattern on say, MCS0->MCS4 over a 4ms long aggregate frame?
>
>
> -adrian
>
> On 25 October 2014 13:35, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>> Thank you for sharing the story.
>> Even if I consider interference as a possibility, still I can't justify the
>> higher
>> chance of frame loss in the second half of the aggregate frame.
>>
>> We use
>>
>> PCI-express 3 antenna dual band cards
>> product: AR93xx Wireless Network Adapter
>> and/or
>> Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop
>>
>> we also tried TP-LINK TL-WDN4200 N900 as the receiver.
>>
>> However we see the same results.
>> we mostly use MCS 20-23, sgi = 0, 20 MHz channels.
>>
>> The loss pattern is something like this
>> (each line is an imaginary aggregated frame and each bit is the fate of the
>> MPDU)
>>
>> 11111111111100011000000000000
>> 11111110001101011010000000000
>> 11111000000000000000000000000
>> 11111111111010100000000000000
>> 11111100101010000000000000000
>>
>> The interesting part is that with the start of the next frame error rate
>> goes down initially
>> then it goes up again in the second portion of the packet.
>>
>> Best,
>> Ali
>>
>>
>>
>>
>>
>> On 25/10/2014 2:30 PM, Adrian Chadd wrote:
>>
>> On 25 October 2014 08:28, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>>
>> 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.
>>
>> Here's a little story.
>>
>> My first wifi contract had me spend months trying to figure out why an
>> AP was losing its mind. It'd get stuck in a "stuck beacon" loop and
>> only a hard powercycle of /all/ of the access points in an area would
>> clear it.
>>
>> It turned out that the PCB design had some non-grounded /
>> non-populated tracks that just "happened" to form a 2GHz resonator.
>> Once we grounded those tracks, the APs started behaving themselves.
>>
>> The company in question spent months with high end spectrum analysis
>> kit in the lab (where it never happened) and underground (where it did
>> happen.) It's only after they stuck the spectrum analyser probe
>> _inside the access point_ right up close to the NIC did they see it.
>>
>> Here's the spectrum analyser traces. You can see the peak.
>>
>> http://www.creative.net.au/ath/
>>
>> So, weirder crap has happened.
>>
>> Which NICs and which MCS rates are you using?
>>
>>
>>
>> -adrian
>>
>>

Re: strange MPDU loss pattern

[Ali Abedi]

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.

Thanks,
Ali


On 14-10-29 04:34 PM, Adrian Chadd wrote:
> Just finally -
>
> MCS20 -> MCS23 are very sensitive to changing channel anything. See if
> you can find or make some required SNR curves for each MCS rate.
>
> So although it doesn't surprise me to find this is happening, it's
> very cute that someone's gone and done the work of figuring out how to
> improve the rate control algorithm to take it into account. I'm kinda
> thinking about how to do that with FreeBSD right now.
>
> Do you get the same pattern on say, MCS0->MCS4 over a 4ms long aggregate frame?
>
>
> -adrian
>
> On 25 October 2014 13:35, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>> Thank you for sharing the story.
>> Even if I consider interference as a possibility, still I can't justify the
>> higher
>> chance of frame loss in the second half of the aggregate frame.
>>
>> We use
>>
>> PCI-express 3 antenna dual band cards
>> product: AR93xx Wireless Network Adapter
>> and/or
>> Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop
>>
>> we also tried TP-LINK TL-WDN4200 N900 as the receiver.
>>
>> However we see the same results.
>> we mostly use MCS 20-23, sgi = 0, 20 MHz channels.
>>
>> The loss pattern is something like this
>> (each line is an imaginary aggregated frame and each bit is the fate of the
>> MPDU)
>>
>> 11111111111100011000000000000
>> 11111110001101011010000000000
>> 11111000000000000000000000000
>> 11111111111010100000000000000
>> 11111100101010000000000000000
>>
>> The interesting part is that with the start of the next frame error rate
>> goes down initially
>> then it goes up again in the second portion of the packet.
>>
>> Best,
>> Ali
>>
>>
>>
>>
>>
>> On 25/10/2014 2:30 PM, Adrian Chadd wrote:
>>
>> On 25 October 2014 08:28, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>>
>> 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.
>>
>> Here's a little story.
>>
>> My first wifi contract had me spend months trying to figure out why an
>> AP was losing its mind. It'd get stuck in a "stuck beacon" loop and
>> only a hard powercycle of /all/ of the access points in an area would
>> clear it.
>>
>> It turned out that the PCB design had some non-grounded /
>> non-populated tracks that just "happened" to form a 2GHz resonator.
>> Once we grounded those tracks, the APs started behaving themselves.
>>
>> The company in question spent months with high end spectrum analysis
>> kit in the lab (where it never happened) and underground (where it did
>> happen.) It's only after they stuck the spectrum analyser probe
>> _inside the access point_ right up close to the NIC did they see it.
>>
>> Here's the spectrum analyser traces. You can see the peak.
>>
>> http://www.creative.net.au/ath/
>>
>> So, weirder crap has happened.
>>
>> Which NICs and which MCS rates are you using?
>>
>>
>>
>> -adrian
>>
>>

[ath9k-devel] strange MPDU loss pattern

[Adrian Chadd]

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

Re: strange MPDU loss pattern

[Adrian Chadd]

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

[ath9k-devel] strange MPDU loss pattern

[Ali Abedi]

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

Re: strange MPDU loss pattern

[Ali Abedi]

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