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

[Ben Greear <greearb@candelatech.com>]

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