Problem with 9984 in routed mode with 512b frames.

Problem with 9984 in routed mode with 512b frames.

[Ben Greear]

Hello,

I found a strange issue and curious if someone has seen similar.

I made an AP where the AP interface acts as a routed interface.  I generate
traffic through another interface in the router.  When sending 300Mbps of 512 byte
UDP payloads, in the downstream direction, and with the station being a 1x1 /AC device,
then the AP NIC appears to mostly lock up within about 1 minute.  I still see beacons, but no
data frames.  In some cases, I reproduced with very slow speed traffic as well.

I tried using a mostly un-modified firmware (ie, similar to upstream QCA), as well as my
hacked upon firmware, and all act similarly.  I'm using the 4.20 kernel, but at least for now,
it does not appear to be a kernel issue.

If I use larger MTU sized frames, or have a 2x2 station instead of 1x1 then it is much harder
to reproduce (and maybe cannot be reproduced).  Also, when generating traffic directly on
the AP device instead of using the routed interface as a traffic source, it is harder to
reproduce.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Sebastian Gottschall]

can you send me a detailed instruction for testing this on my devices? 
so which commands have been used for generating the traffic etc. (iperf3?)

Sebastian

Am 15.05.2019 um 03:52 schrieb Ben Greear:
> Hello,
>
> I found a strange issue and curious if someone has seen similar.
>
> I made an AP where the AP interface acts as a routed interface.  I 
> generate
> traffic through another interface in the router.  When sending 300Mbps 
> of 512 byte
> UDP payloads, in the downstream direction, and with the station being 
> a 1x1 /AC device,
> then the AP NIC appears to mostly lock up within about 1 minute. I 
> still see beacons, but no
> data frames.  In some cases, I reproduced with very slow speed traffic 
> as well.
>
> I tried using a mostly un-modified firmware (ie, similar to upstream 
> QCA), as well as my
> hacked upon firmware, and all act similarly.  I'm using the 4.20 
> kernel, but at least for now,
> it does not appear to be a kernel issue.
>
> If I use larger MTU sized frames, or have a 2x2 station instead of 1x1 
> then it is much harder
> to reproduce (and maybe cannot be reproduced).  Also, when generating 
> traffic directly on
> the AP device instead of using the routed interface as a traffic 
> source, it is harder to
> reproduce.
>
> Thanks,
> Ben
>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Ben Greear]

On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?)

I am using our own traffic generator, but I imagine iperf3 should work fine too.

I am testing on x86-64 and so forth.  Maybe you can test with UDP small-packet load on your platform
in routed mode (ie, external iperf generator through your AP) and see if you see issues?

 From debugging yesterday, I see a lot of tx-hang notifications in the firmware, and
I also believe I saw it trying to transmit with a 0 rate-indx, which is 11Mbps CCK,
which is invalid for 5Ghz.  I'll be debugging that more today.  I don't know if stock
firmware fails for the same reasons, but the symptom looked the same.

Thanks,
Ben

>
> Sebastian
>
> Am 15.05.2019 um 03:52 schrieb Ben Greear:
>> Hello,
>>
>> I found a strange issue and curious if someone has seen similar.
>>
>> I made an AP where the AP interface acts as a routed interface.  I generate
>> traffic through another interface in the router.  When sending 300Mbps of 512 byte
>> UDP payloads, in the downstream direction, and with the station being a 1x1 /AC device,
>> then the AP NIC appears to mostly lock up within about 1 minute. I still see beacons, but no
>> data frames.  In some cases, I reproduced with very slow speed traffic as well.
>>
>> I tried using a mostly un-modified firmware (ie, similar to upstream QCA), as well as my
>> hacked upon firmware, and all act similarly.  I'm using the 4.20 kernel, but at least for now,
>> it does not appear to be a kernel issue.
>>
>> If I use larger MTU sized frames, or have a 2x2 station instead of 1x1 then it is much harder
>> to reproduce (and maybe cannot be reproduced).  Also, when generating traffic directly on
>> the AP device instead of using the routed interface as a traffic source, it is harder to
>> reproduce.
>>
>> Thanks,
>> Ben
>>
>

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Sebastian Gottschall]

Am 15.05.2019 um 14:20 schrieb Ben Greear:
> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
>> can you send me a detailed instruction for testing this on my 
>> devices? so which commands have been used for generating the traffic 
>> etc. (iperf3?)
>
> I am using our own traffic generator, but I imagine iperf3 should work 
> fine too.
>
> I am testing on x86-64 and so forth.  Maybe you can test with UDP 
> small-packet load on your platform
> in routed mode (ie, external iperf generator through your AP) and see 
> if you see issues?
thats the plan. can you do a test with iperf3 to see if its 
reproduceable. i mean i will test it on ipq based boards and x64. but to 
make sure that the scenario
is identical which raised up your issue, it would be find if we have 
identical software for testing including the same options
>
> From debugging yesterday, I see a lot of tx-hang notifications in the 
> firmware, and
> I also believe I saw it trying to transmit with a 0 rate-indx, which 
> is 11Mbps CCK,
> which is invalid for 5Ghz.  I'll be debugging that more today.  I 
> don't know if stock
> firmware fails for the same reasons, but the symptom looked the same.
could be a buffer overflow/locking due a udp flooding. so a missing 
check to drop packets which are out of limit or a too restrictive buffer 
management.
like static frame buffers of max mtu size, but its just used partially 
by frame due the small size of the udp packets. you may know it better 
since you have much better
knowledge about the firmware internals.
>
> Thanks,
> Ben
>
>>
>> Sebastian
>>
>> Am 15.05.2019 um 03:52 schrieb Ben Greear:
>>> Hello,
>>>
>>> I found a strange issue and curious if someone has seen similar.
>>>
>>> I made an AP where the AP interface acts as a routed interface.  I 
>>> generate
>>> traffic through another interface in the router.  When sending 
>>> 300Mbps of 512 byte
>>> UDP payloads, in the downstream direction, and with the station 
>>> being a 1x1 /AC device,
>>> then the AP NIC appears to mostly lock up within about 1 minute. I 
>>> still see beacons, but no
>>> data frames.  In some cases, I reproduced with very slow speed 
>>> traffic as well.
>>>
>>> I tried using a mostly un-modified firmware (ie, similar to upstream 
>>> QCA), as well as my
>>> hacked upon firmware, and all act similarly.  I'm using the 4.20 
>>> kernel, but at least for now,
>>> it does not appear to be a kernel issue.
>>>
>>> If I use larger MTU sized frames, or have a 2x2 station instead of 
>>> 1x1 then it is much harder
>>> to reproduce (and maybe cannot be reproduced).  Also, when 
>>> generating traffic directly on
>>> the AP device instead of using the routed interface as a traffic 
>>> source, it is harder to
>>> reproduce.
>>>
>>> Thanks,
>>> Ben
>>>
>>
>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Ben Greear]

On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
> 
> Am 15.05.2019 um 14:20 schrieb Ben Greear:
>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?)
>>
>> I am using our own traffic generator, but I imagine iperf3 should work fine too.
>>
>> I am testing on x86-64 and so forth.  Maybe you can test with UDP small-packet load on your platform
>> in routed mode (ie, external iperf generator through your AP) and see if you see issues?
> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario
> is identical which raised up your issue, it would be find if we have identical software for testing including the same options

One of our other engineers will try to reproduce it on a different system today.

And in case you are sniffing during your own testing, I'd be curious if you see
any AMSDU frames?  I only see AMPDUS full of single-packet frames.  I would expect
several of the 512b frames to be put into AMSDU sub-frames.  I plan to look into that
after I figure out the tx stall issue.

Thanks,
Ben

>>
>> From debugging yesterday, I see a lot of tx-hang notifications in the firmware, and
>> I also believe I saw it trying to transmit with a 0 rate-indx, which is 11Mbps CCK,
>> which is invalid for 5Ghz.  I'll be debugging that more today.  I don't know if stock
>> firmware fails for the same reasons, but the symptom looked the same.
> could be a buffer overflow/locking due a udp flooding. so a missing check to drop packets which are out of limit or a too restrictive buffer management.
> like static frame buffers of max mtu size, but its just used partially by frame due the small size of the udp packets. you may know it better since you have 
> much better
> knowledge about the firmware internals.
>>
>> Thanks,
>> Ben
>>
>>>
>>> Sebastian
>>>
>>> Am 15.05.2019 um 03:52 schrieb Ben Greear:
>>>> Hello,
>>>>
>>>> I found a strange issue and curious if someone has seen similar.
>>>>
>>>> I made an AP where the AP interface acts as a routed interface.  I generate
>>>> traffic through another interface in the router.  When sending 300Mbps of 512 byte
>>>> UDP payloads, in the downstream direction, and with the station being a 1x1 /AC device,
>>>> then the AP NIC appears to mostly lock up within about 1 minute. I still see beacons, but no
>>>> data frames.  In some cases, I reproduced with very slow speed traffic as well.
>>>>
>>>> I tried using a mostly un-modified firmware (ie, similar to upstream QCA), as well as my
>>>> hacked upon firmware, and all act similarly.  I'm using the 4.20 kernel, but at least for now,
>>>> it does not appear to be a kernel issue.
>>>>
>>>> If I use larger MTU sized frames, or have a 2x2 station instead of 1x1 then it is much harder
>>>> to reproduce (and maybe cannot be reproduced).  Also, when generating traffic directly on
>>>> the AP device instead of using the routed interface as a traffic source, it is harder to
>>>> reproduce.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>
>>
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Ben Greear]

On 5/15/19 6:00 AM, Ben Greear wrote:
> On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
>>
>> Am 15.05.2019 um 14:20 schrieb Ben Greear:
>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
>>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?)
>>>
>>> I am using our own traffic generator, but I imagine iperf3 should work fine too.
>>>
>>> I am testing on x86-64 and so forth.  Maybe you can test with UDP small-packet load on your platform
>>> in routed mode (ie, external iperf generator through your AP) and see if you see issues?
>> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario
>> is identical which raised up your issue, it would be find if we have identical software for testing including the same options

I think I found the issue.  The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates.
It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the
single OFDM rate is the fault).

If you can edit firmware, then setting this to 0 probably fixes the issue.

g_rc_cck_rate_allowed

I think to reproduce you'd need to send high speed traffic in a situation where the
RF environment is going to make rate-ctrl fail quite a bit.  (Slow speed should
work too, but it would likely take a lot longer).

And, it is always possible that whatever I saw when testing mostly-stock FW is different
from what I eventually debugged to in my firmware.  Still, from looking at MCS vs SNR
charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Adrian Chadd]

You can totally go down to OFDM yeah but you then need to send it at
20MHz and non-AMPDU.

Is it maybe the retry code + rate control code is retagging an AMPDU
at a lower rate and it's transitioning down to CCK/OFDM without
breaking the AMPDU apart?


-a

On Thu, 16 May 2019 at 12:40, Ben Greear <greearb@candelatech.com> wrote:
>
> On 5/15/19 6:00 AM, Ben Greear wrote:
> > On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
> >>
> >> Am 15.05.2019 um 14:20 schrieb Ben Greear:
> >>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
> >>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?)
> >>>
> >>> I am using our own traffic generator, but I imagine iperf3 should work fine too.
> >>>
> >>> I am testing on x86-64 and so forth.  Maybe you can test with UDP small-packet load on your platform
> >>> in routed mode (ie, external iperf generator through your AP) and see if you see issues?
> >> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario
> >> is identical which raised up your issue, it would be find if we have identical software for testing including the same options
>
> I think I found the issue.  The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates.
> It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the
> single OFDM rate is the fault).
>
> If you can edit firmware, then setting this to 0 probably fixes the issue.
>
> g_rc_cck_rate_allowed
>
> I think to reproduce you'd need to send high speed traffic in a situation where the
> RF environment is going to make rate-ctrl fail quite a bit.  (Slow speed should
> work too, but it would likely take a lot longer).
>
> And, it is always possible that whatever I saw when testing mostly-stock FW is different
> from what I eventually debugged to in my firmware.  Still, from looking at MCS vs SNR
> charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Ben Greear]

On 5/16/19 12:55 PM, Adrian Chadd wrote:
> You can totally go down to OFDM yeah but you then need to send it at
> 20MHz and non-AMPDU.
> 
> Is it maybe the retry code + rate control code is retagging an AMPDU
> at a lower rate and it's transitioning down to CCK/OFDM without
> breaking the AMPDU apart?

It was sending a one-frame AMPDU, and one frame AMSDU for that matter.  Maybe
there is some bit in the tx descriptor that needed to be twiddled as well
to make OFDM able to work, but I don't know what that would be.

Is there any advantage of (any) OFDM over MCS0 HT 20Mhz as far as range or
SNR goes?  The chart I found made it look like there was not, and if
not, then why bother at all with OFDM if peer advertises HT/VHT rates?

Thanks,
Ben

> 
> 
> -a
> 
> On Thu, 16 May 2019 at 12:40, Ben Greear <greearb@candelatech.com> wrote:
>>
>> On 5/15/19 6:00 AM, Ben Greear wrote:
>>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
>>>>
>>>> Am 15.05.2019 um 14:20 schrieb Ben Greear:
>>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
>>>>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?)
>>>>>
>>>>> I am using our own traffic generator, but I imagine iperf3 should work fine too.
>>>>>
>>>>> I am testing on x86-64 and so forth.  Maybe you can test with UDP small-packet load on your platform
>>>>> in routed mode (ie, external iperf generator through your AP) and see if you see issues?
>>>> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario
>>>> is identical which raised up your issue, it would be find if we have identical software for testing including the same options
>>
>> I think I found the issue.  The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates.
>> It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the
>> single OFDM rate is the fault).
>>
>> If you can edit firmware, then setting this to 0 probably fixes the issue.
>>
>> g_rc_cck_rate_allowed
>>
>> I think to reproduce you'd need to send high speed traffic in a situation where the
>> RF environment is going to make rate-ctrl fail quite a bit.  (Slow speed should
>> work too, but it would likely take a lot longer).
>>
>> And, it is always possible that whatever I saw when testing mostly-stock FW is different
>> from what I eventually debugged to in my firmware.  Still, from looking at MCS vs SNR
>> charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz.
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Adrian Chadd]

You can't do AMPDU with OFDM/CCK. If they're setting the AMPDU bit
then that's wrong. it needs to be individual MPDU/PPDUs.

There's a benefit for CCK. OFDM 6M is I think roughly the same as OFDM
MCS0. But CCK is a lot more reliable.


-adrian

On Thu, 16 May 2019 at 13:10, Ben Greear <greearb@candelatech.com> wrote:
>
> On 5/16/19 12:55 PM, Adrian Chadd wrote:
> > You can totally go down to OFDM yeah but you then need to send it at
> > 20MHz and non-AMPDU.
> >
> > Is it maybe the retry code + rate control code is retagging an AMPDU
> > at a lower rate and it's transitioning down to CCK/OFDM without
> > breaking the AMPDU apart?
>
> It was sending a one-frame AMPDU, and one frame AMSDU for that matter.  Maybe
> there is some bit in the tx descriptor that needed to be twiddled as well
> to make OFDM able to work, but I don't know what that would be.
>
> Is there any advantage of (any) OFDM over MCS0 HT 20Mhz as far as range or
> SNR goes?  The chart I found made it look like there was not, and if
> not, then why bother at all with OFDM if peer advertises HT/VHT rates?
>
> Thanks,
> Ben
>
> >
> >
> > -a
> >
> > On Thu, 16 May 2019 at 12:40, Ben Greear <greearb@candelatech.com> wrote:
> >>
> >> On 5/15/19 6:00 AM, Ben Greear wrote:
> >>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
> >>>>
> >>>> Am 15.05.2019 um 14:20 schrieb Ben Greear:
> >>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
> >>>>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?)
> >>>>>
> >>>>> I am using our own traffic generator, but I imagine iperf3 should work fine too.
> >>>>>
> >>>>> I am testing on x86-64 and so forth.  Maybe you can test with UDP small-packet load on your platform
> >>>>> in routed mode (ie, external iperf generator through your AP) and see if you see issues?
> >>>> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario
> >>>> is identical which raised up your issue, it would be find if we have identical software for testing including the same options
> >>
> >> I think I found the issue.  The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates.
> >> It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the
> >> single OFDM rate is the fault).
> >>
> >> If you can edit firmware, then setting this to 0 probably fixes the issue.
> >>
> >> g_rc_cck_rate_allowed
> >>
> >> I think to reproduce you'd need to send high speed traffic in a situation where the
> >> RF environment is going to make rate-ctrl fail quite a bit.  (Slow speed should
> >> work too, but it would likely take a lot longer).
> >>
> >> And, it is always possible that whatever I saw when testing mostly-stock FW is different
> >> from what I eventually debugged to in my firmware.  Still, from looking at MCS vs SNR
> >> charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz.
> >>
> >> Thanks,
> >> Ben
> >>
> >> --
> >> Ben Greear <greearb@candelatech.com>
> >> Candela Technologies Inc  http://www.candelatech.com
> >>
> >>
> >> _______________________________________________
> >> ath10k mailing list
> >> ath10k@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/ath10k
> >
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Ben Greear]

On 5/16/19 1:16 PM, Adrian Chadd wrote:
> You can't do AMPDU with OFDM/CCK. If they're setting the AMPDU bit
> then that's wrong. it needs to be individual MPDU/PPDUs.
> 
> There's a benefit for CCK. OFDM 6M is I think roughly the same as OFDM
> MCS0. But CCK is a lot more reliable.

5Ghz can (should) not do CCK anyway.  Do you have any reference for why
you think CCK will be better?  The one I found shows otherwise:

https://d2cpnw0u24fjm4.cloudfront.net/wp-content/uploads/LaminatedCard_RevolutionWiFiMCStoSNRSinglePage.png

Thanks,
Ben

> 
> 
> -adrian
> 
> On Thu, 16 May 2019 at 13:10, Ben Greear <greearb@candelatech.com> wrote:
>>
>> On 5/16/19 12:55 PM, Adrian Chadd wrote:
>>> You can totally go down to OFDM yeah but you then need to send it at
>>> 20MHz and non-AMPDU.
>>>
>>> Is it maybe the retry code + rate control code is retagging an AMPDU
>>> at a lower rate and it's transitioning down to CCK/OFDM without
>>> breaking the AMPDU apart?
>>
>> It was sending a one-frame AMPDU, and one frame AMSDU for that matter.  Maybe
>> there is some bit in the tx descriptor that needed to be twiddled as well
>> to make OFDM able to work, but I don't know what that would be.
>>
>> Is there any advantage of (any) OFDM over MCS0 HT 20Mhz as far as range or
>> SNR goes?  The chart I found made it look like there was not, and if
>> not, then why bother at all with OFDM if peer advertises HT/VHT rates?
>>
>> Thanks,
>> Ben
>>
>>>
>>>
>>> -a
>>>
>>> On Thu, 16 May 2019 at 12:40, Ben Greear <greearb@candelatech.com> wrote:
>>>>
>>>> On 5/15/19 6:00 AM, Ben Greear wrote:
>>>>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
>>>>>>
>>>>>> Am 15.05.2019 um 14:20 schrieb Ben Greear:
>>>>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
>>>>>>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?)
>>>>>>>
>>>>>>> I am using our own traffic generator, but I imagine iperf3 should work fine too.
>>>>>>>
>>>>>>> I am testing on x86-64 and so forth.  Maybe you can test with UDP small-packet load on your platform
>>>>>>> in routed mode (ie, external iperf generator through your AP) and see if you see issues?
>>>>>> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario
>>>>>> is identical which raised up your issue, it would be find if we have identical software for testing including the same options
>>>>
>>>> I think I found the issue.  The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates.
>>>> It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the
>>>> single OFDM rate is the fault).
>>>>
>>>> If you can edit firmware, then setting this to 0 probably fixes the issue.
>>>>
>>>> g_rc_cck_rate_allowed
>>>>
>>>> I think to reproduce you'd need to send high speed traffic in a situation where the
>>>> RF environment is going to make rate-ctrl fail quite a bit.  (Slow speed should
>>>> work too, but it would likely take a lot longer).
>>>>
>>>> And, it is always possible that whatever I saw when testing mostly-stock FW is different
>>>> from what I eventually debugged to in my firmware.  Still, from looking at MCS vs SNR
>>>> charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>> --
>>>> Ben Greear <greearb@candelatech.com>
>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Adrian Chadd]

On Thu, 16 May 2019 at 13:20, Ben Greear <greearb@candelatech.com> wrote:
>
> On 5/16/19 1:16 PM, Adrian Chadd wrote:
> > You can't do AMPDU with OFDM/CCK. If they're setting the AMPDU bit
> > then that's wrong. it needs to be individual MPDU/PPDUs.
> >
> > There's a benefit for CCK. OFDM 6M is I think roughly the same as OFDM
> > MCS0. But CCK is a lot more reliable.
>
> 5Ghz can (should) not do CCK anyway.  Do you have any reference for why
> you think CCK will be better?  The one I found shows otherwise:
>
> https://d2cpnw0u24fjm4.cloudfront.net/wp-content/uploads/LaminatedCard_RevolutionWiFiMCStoSNRSinglePage.png

Well, you should try measuring it :-) I remember stories of decoding
CCK frames with MRC-CCK at an RSSI of 0 or -1...

And yes, you shouldn't do CCK on 5G, but some wifi PHYs do support it
("support" "it")...



-adrian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Sebastian Gottschall]

Am 16.05.2019 um 21:40 schrieb Ben Greear:
> On 5/15/19 6:00 AM, Ben Greear wrote:
>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
>>>
>>> Am 15.05.2019 um 14:20 schrieb Ben Greear:
>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
>>>>> can you send me a detailed instruction for testing this on my 
>>>>> devices? so which commands have been used for generating the 
>>>>> traffic etc. (iperf3?)
>>>>
>>>> I am using our own traffic generator, but I imagine iperf3 should 
>>>> work fine too.
>>>>
>>>> I am testing on x86-64 and so forth.  Maybe you can test with UDP 
>>>> small-packet load on your platform
>>>> in routed mode (ie, external iperf generator through your AP) and 
>>>> see if you see issues?
>>> thats the plan. can you do a test with iperf3 to see if its 
>>> reproduceable. i mean i will test it on ipq based boards and x64. 
>>> but to make sure that the scenario
>>> is identical which raised up your issue, it would be find if we have 
>>> identical software for testing including the same options
>
> I think I found the issue.  The rate-ctrl logic in the firmware allows 
> a transition from HT/VHT 20 MCS0 down to OFDM rates.
> It seems the hardware does not like to see an AMPDU with an OFDM rate 
> for 20Mhz and a VHT rate for 80Mhz (or maybe just the
> single OFDM rate is the fault).
>
> If you can edit firmware, then setting this to 0 probably fixes the 
> issue.
>
> g_rc_cck_rate_allowed

according to the code this variable has only effect on 2.4 ghz. the 
fallback to cck rates will only be done if phymode is 2.4 ghz


>
> I think to reproduce you'd need to send high speed traffic in a 
> situation where the
> RF environment is going to make rate-ctrl fail quite a bit.  (Slow 
> speed should
> work too, but it would likely take a lot longer).
>
> And, it is always possible that whatever I saw when testing 
> mostly-stock FW is different
> from what I eventually debugged to in my firmware.  Still, from 
> looking at MCS vs SNR
> charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz.
>
> Thanks,
> Ben
>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Ben Greear]

On 05/16/2019 09:21 PM, Sebastian Gottschall wrote:
>
> Am 16.05.2019 um 21:40 schrieb Ben Greear:
>> On 5/15/19 6:00 AM, Ben Greear wrote:
>>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
>>>>
>>>> Am 15.05.2019 um 14:20 schrieb Ben Greear:
>>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
>>>>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?)
>>>>>
>>>>> I am using our own traffic generator, but I imagine iperf3 should work fine too.
>>>>>
>>>>> I am testing on x86-64 and so forth.  Maybe you can test with UDP small-packet load on your platform
>>>>> in routed mode (ie, external iperf generator through your AP) and see if you see issues?
>>>> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario
>>>> is identical which raised up your issue, it would be find if we have identical software for testing including the same options
>>
>> I think I found the issue.  The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates.
>> It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the
>> single OFDM rate is the fault).
>>
>> If you can edit firmware, then setting this to 0 probably fixes the issue.
>>
>> g_rc_cck_rate_allowed
>
> according to the code this variable has only effect on 2.4 ghz. the fallback to cck rates will only be done if phymode is 2.4 ghz

Ok, maybe the symptom I saw with stock-ish firmware was due to some other cause.  In my firmware,
I had "fixed" that cck-fallback to use OFDM rates in case CCK was not available, so mine was
definitely trying to use an OFDM rate.

That said, very likely the same bug exists in upstream QCA firmware for 2.4Ghz radios where CCK is available,
so still might be worth fixing or at least adding API to let the user disable the fallback in case strange
problems are seen.

I am guessing that if it really wants to send OFDM/CCK rates, then it will have to use a different
TID that is not set up for AMPDUs, and the current code does not deal with that as far as I can tell.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Sebastian Gottschall]

Am 17.05.2019 um 13:48 schrieb Ben Greear:
>
>
> On 05/16/2019 09:21 PM, Sebastian Gottschall wrote:
>>
>> Am 16.05.2019 um 21:40 schrieb Ben Greear:
>>> On 5/15/19 6:00 AM, Ben Greear wrote:
>>>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
>>>>>
>>>>> Am 15.05.2019 um 14:20 schrieb Ben Greear:
>>>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
>>>>>>> can you send me a detailed instruction for testing this on my 
>>>>>>> devices? so which commands have been used for generating the 
>>>>>>> traffic etc. (iperf3?)
>>>>>>
>>>>>> I am using our own traffic generator, but I imagine iperf3 should 
>>>>>> work fine too.
>>>>>>
>>>>>> I am testing on x86-64 and so forth.  Maybe you can test with UDP 
>>>>>> small-packet load on your platform
>>>>>> in routed mode (ie, external iperf generator through your AP) and 
>>>>>> see if you see issues?
>>>>> thats the plan. can you do a test with iperf3 to see if its 
>>>>> reproduceable. i mean i will test it on ipq based boards and x64. 
>>>>> but to make sure that the scenario
>>>>> is identical which raised up your issue, it would be find if we 
>>>>> have identical software for testing including the same options
>>>
>>> I think I found the issue.  The rate-ctrl logic in the firmware 
>>> allows a transition from HT/VHT 20 MCS0 down to OFDM rates.
>>> It seems the hardware does not like to see an AMPDU with an OFDM 
>>> rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the
>>> single OFDM rate is the fault).
>>>
>>> If you can edit firmware, then setting this to 0 probably fixes the 
>>> issue.
>>>
>>> g_rc_cck_rate_allowed
>>
>> according to the code this variable has only effect on 2.4 ghz. the 
>> fallback to cck rates will only be done if phymode is 2.4 ghz
>
> Ok, maybe the symptom I saw with stock-ish firmware was due to some 
> other cause.  In my firmware,
> I had "fixed" that cck-fallback to use OFDM rates in case CCK was not 
> available, so mine was
> definitely trying to use an OFDM rate.
>
> That said, very likely the same bug exists in upstream QCA firmware 
> for 2.4Ghz radios where CCK is available,
> so still might be worth fixing or at least adding API to let the user 
> disable the fallback in case strange
> problems are seen.
>
> I am guessing that if it really wants to send OFDM/CCK rates, then it 
> will have to use a different
> TID that is not set up for AMPDUs, and the current code does not deal 
> with that as far as I can tell.
personally i think going back to basic rates like 2 mbit makes no sense 
anyway. its that dead slow that a connection must break and has to be 
broken if this doesnt work.
still a shame that beacons are still transmitted in this way and 
multicast/broadcast packets as well which causes a hell of problems. but 
thats for backward compatibility of cause
>
> Thanks,
> Ben
>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Adrian Chadd]

On Fri, 17 May 2019 at 08:06, Sebastian Gottschall
<s.gottschall@newmedia-net.de> wrote:


> personally i think going back to basic rates like 2 mbit makes no sense
> anyway. its that dead slow that a connection must break and has to be
> broken if this doesnt work.
> still a shame that beacons are still transmitted in this way and
> multicast/broadcast packets as well which causes a hell of problems. but
> thats for backward compatibility of cause

It depends on what kind of channel you are. Not everyone is deploying
super dense enterprise APs. :-)

The 11ac and 11ax chips that do constant frequency readjusting work
better in things like moving drones, where you have constant doppler
shift. I know some people doing drone work that just don't bother with
MCS and aggregation because they need a super reliable channel and the
conditions constantly shift.

That said, they're very sad that they can't hack on the 11ac/11ax
firmware to fix some err, less optimal decisions in their use case
space like they can with ath5k/ath9k.

ISTR back at QCA days there were some people on the systems team that
could demonstrate CCK was more stable in some use cases and so didn't
like the Linux rate control behaviour of not falling back to CCK in 2G
11n mode. There was .. pushback against the linux upstream rate
control in this respect right until the linux folk totally deprecated
the QCA rate control in ath9k. :)

(And then bugs like what ben is seeing :)

Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit
that tries to send AMPDU frames in non-11n rates?


-adrian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Ben Greear]

On 5/17/19 8:47 AM, Adrian Chadd wrote:
> On Fri, 17 May 2019 at 08:06, Sebastian Gottschall
> <s.gottschall@newmedia-net.de> wrote:
> 
> 
>> personally i think going back to basic rates like 2 mbit makes no sense
>> anyway. its that dead slow that a connection must break and has to be
>> broken if this doesnt work.
>> still a shame that beacons are still transmitted in this way and
>> multicast/broadcast packets as well which causes a hell of problems. but
>> thats for backward compatibility of cause
> 
> It depends on what kind of channel you are. Not everyone is deploying
> super dense enterprise APs. :-)
> 
> The 11ac and 11ax chips that do constant frequency readjusting work
> better in things like moving drones, where you have constant doppler
> shift. I know some people doing drone work that just don't bother with
> MCS and aggregation because they need a super reliable channel and the
> conditions constantly shift.
> 
> That said, they're very sad that they can't hack on the 11ac/11ax
> firmware to fix some err, less optimal decisions in their use case
> space like they can with ath5k/ath9k.
> 
> ISTR back at QCA days there were some people on the systems team that
> could demonstrate CCK was more stable in some use cases and so didn't
> like the Linux rate control behaviour of not falling back to CCK in 2G
> 11n mode. There was .. pushback against the linux upstream rate
> control in this respect right until the linux folk totally deprecated
> the QCA rate control in ath9k. :)
> 
> (And then bugs like what ben is seeing :)
> 
> Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit
> that tries to send AMPDU frames in non-11n rates?

Yes, disabling the fallback appears to have fixed my issue.

I did not try to fix the fallback code because I think it will be quite
complicated to do it properly (I suspect a different tid must be used for this
to work).  I'm not even entirely sure of exactly why the transmit logic fails
in this case, and by the time rate-ctrl logic is queried, I think it is too
late to easily change tids.

And FYI, in my firmware/driver, you can now specify the exact preamble-type, mcs, bandwidth, txpower,
retransmit count, etc on a per packet basis.  I'm not sure of all the bugs and limitations
in this code, but it at least mostly works as hoped for the ways we are using it
(rx sensitivity test rigs, etc).

Might be of interest if someone wants to do a somewhat limited user-space rate-ctrl for
ath10k wave-2.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Adrian Chadd]

On Fri, 17 May 2019 at 09:00, Ben Greear <greearb@candelatech.com> wrote:
>
> On 5/17/19 8:47 AM, Adrian Chadd wrote:
> > On Fri, 17 May 2019 at 08:06, Sebastian Gottschall
> > <s.gottschall@newmedia-net.de> wrote:
> >
> >
> >> personally i think going back to basic rates like 2 mbit makes no sense
> >> anyway. its that dead slow that a connection must break and has to be
> >> broken if this doesnt work.
> >> still a shame that beacons are still transmitted in this way and
> >> multicast/broadcast packets as well which causes a hell of problems. but
> >> thats for backward compatibility of cause
> >
> > It depends on what kind of channel you are. Not everyone is deploying
> > super dense enterprise APs. :-)
> >
> > The 11ac and 11ax chips that do constant frequency readjusting work
> > better in things like moving drones, where you have constant doppler
> > shift. I know some people doing drone work that just don't bother with
> > MCS and aggregation because they need a super reliable channel and the
> > conditions constantly shift.
> >
> > That said, they're very sad that they can't hack on the 11ac/11ax
> > firmware to fix some err, less optimal decisions in their use case
> > space like they can with ath5k/ath9k.
> >
> > ISTR back at QCA days there were some people on the systems team that
> > could demonstrate CCK was more stable in some use cases and so didn't
> > like the Linux rate control behaviour of not falling back to CCK in 2G
> > 11n mode. There was .. pushback against the linux upstream rate
> > control in this respect right until the linux folk totally deprecated
> > the QCA rate control in ath9k. :)
> >
> > (And then bugs like what ben is seeing :)
> >
> > Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit
> > that tries to send AMPDU frames in non-11n rates?
>
> Yes, disabling the fallback appears to have fixed my issue.
>
> I did not try to fix the fallback code because I think it will be quite
> complicated to do it properly (I suspect a different tid must be used for this
> to work).  I'm not even entirely sure of exactly why the transmit logic fails
> in this case, and by the time rate-ctrl logic is queried, I think it is too
> late to easily change tids.

Ok. I'll reach to you offline (irc maybe?) and let's see if we can get
QCA to fix this in their firmware. I know there's a LOT of things that
need fixing in the upstream firmware but this is a pretty big bug that
needs squishing for everyone.

Thanks!


-adrian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Sebastian Gottschall]

Am 17.05.2019 um 17:47 schrieb Adrian Chadd:
> On Fri, 17 May 2019 at 08:06, Sebastian Gottschall
> <s.gottschall@newmedia-net.de> wrote:
>
>
>> personally i think going back to basic rates like 2 mbit makes no sense
>> anyway. its that dead slow that a connection must break and has to be
>> broken if this doesnt work.
>> still a shame that beacons are still transmitted in this way and
>> multicast/broadcast packets as well which causes a hell of problems. but
>> thats for backward compatibility of cause
> It depends on what kind of channel you are. Not everyone is deploying
> super dense enterprise APs. :-)
>
> The 11ac and 11ax chips that do constant frequency readjusting work
> better in things like moving drones, where you have constant doppler
> shift. I know some people doing drone work that just don't bother with
> MCS and aggregation because they need a super reliable channel and the
> conditions constantly shift.
>
> That said, they're very sad that they can't hack on the 11ac/11ax
> firmware to fix some err, less optimal decisions in their use case
> space like they can with ath5k/ath9k.
>
> ISTR back at QCA days there were some people on the systems team that
> could demonstrate CCK was more stable in some use cases and so didn't
> like the Linux rate control behaviour of not falling back to CCK in 2G
> 11n mode. There was .. pushback against the linux upstream rate
> control in this respect right until the linux folk totally deprecated
> the QCA rate control in ath9k. :)
CCK is dead stable of cause, but also dead slow and its blocking the 
channel which decreases performance for all other people
>
> (And then bugs like what ben is seeing :)
>
> Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit
> that tries to send AMPDU frames in non-11n rates?
>
>
> -adrian
>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Sebastian Gottschall]

Am 17.05.2019 um 18:00 schrieb Ben Greear:
> On 5/17/19 8:47 AM, Adrian Chadd wrote:
>> On Fri, 17 May 2019 at 08:06, Sebastian Gottschall
>> <s.gottschall@newmedia-net.de> wrote:
>>
>>
>>> personally i think going back to basic rates like 2 mbit makes no sense
>>> anyway. its that dead slow that a connection must break and has to be
>>> broken if this doesnt work.
>>> still a shame that beacons are still transmitted in this way and
>>> multicast/broadcast packets as well which causes a hell of problems. 
>>> but
>>> thats for backward compatibility of cause
>>
>> It depends on what kind of channel you are. Not everyone is deploying
>> super dense enterprise APs. :-)
>>
>> The 11ac and 11ax chips that do constant frequency readjusting work
>> better in things like moving drones, where you have constant doppler
>> shift. I know some people doing drone work that just don't bother with
>> MCS and aggregation because they need a super reliable channel and the
>> conditions constantly shift.
>>
>> That said, they're very sad that they can't hack on the 11ac/11ax
>> firmware to fix some err, less optimal decisions in their use case
>> space like they can with ath5k/ath9k.
>>
>> ISTR back at QCA days there were some people on the systems team that
>> could demonstrate CCK was more stable in some use cases and so didn't
>> like the Linux rate control behaviour of not falling back to CCK in 2G
>> 11n mode. There was .. pushback against the linux upstream rate
>> control in this respect right until the linux folk totally deprecated
>> the QCA rate control in ath9k. :)
>>
>> (And then bugs like what ben is seeing :)
>>
>> Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit
>> that tries to send AMPDU frames in non-11n rates?
>
> Yes, disabling the fallback appears to have fixed my issue.
>
> I did not try to fix the fallback code because I think it will be quite
> complicated to do it properly (I suspect a different tid must be used 
> for this
> to work).  I'm not even entirely sure of exactly why the transmit 
> logic fails
> in this case, and by the time rate-ctrl logic is queried, I think it 
> is too
> late to easily change tids.
>
> And FYI, in my firmware/driver, you can now specify the exact 
> preamble-type, mcs, bandwidth, txpower,
> retransmit count, etc on a per packet basis.  I'm not sure of all the 
> bugs and limitations
> in this code, but it at least mostly works as hoped for the ways we 
> are using it
> (rx sensitivity test rigs, etc).
>
> Might be of interest if someone wants to do a somewhat limited 
> user-space rate-ctrl for
> ath10k wave-2.
the curious thing is still that the fallback code applies only for 2.4 
ghz so it would never have affected 802.11ac
>
> Thanks,
> Ben
>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Adrian Chadd]

On Mon, 20 May 2019 at 09:59, Sebastian Gottschall
<s.gottschall@newmedia-net.de> wrote:


> the curious thing is still that the fallback code applies only for 2.4
> ghz so it would never have affected 802.11ac

Hm, does RC fall back to 11na or 11a rates when doing 11ac? (in 5G
mode.) It's good to know fixing that would fix it in 2.4GHz operation
but yeah, I wonder about RC in 5G.


-adian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Problem with 9984 in routed mode with 512b frames.

[Ben Greear]

On 5/20/19 12:25 PM, Adrian Chadd wrote:
> On Mon, 20 May 2019 at 09:59, Sebastian Gottschall
> <s.gottschall@newmedia-net.de> wrote:
> 
> 
>> the curious thing is still that the fallback code applies only for 2.4
>> ghz so it would never have affected 802.11ac
> 
> Hm, does RC fall back to 11na or 11a rates when doing 11ac? (in 5G
> mode.) It's good to know fixing that would fix it in 2.4GHz operation
> but yeah, I wonder about RC in 5G.

It appears the rate-ctrl tries to fall to CCK 2Mbps or 1Mbps and skips a/g rates.  /n
rates are a subset of VHT, so those are used as part of normal VHT rate-ctrl.

I have no explanation for why I saw the tx-hang in stock-ish firmware, which indeed
should not have tried to use any a/g rates in 5Ghz.  The high-level failure looked exactly like
what I eventually debugged as falling back to /a rates in my firmware, for what that
is worth.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k