VHT 160Mhz and nss related config.

[Ben Greear]

On 02/13/2017 02:48 PM, Sebastian Gottschall wrote:
> Am 13.02.2017 um 20:56 schrieb Ben Greear:
>> On 02/11/2017 10:21 AM, Sebastian Gottschall wrote:
>>> Am 11.02.2017 um 18:58 schrieb Ben Greear:
>>>> On 02/10/2017 08:37 PM, Adrian Chadd wrote:
>>>>> On 10 February 2017 at 20:22, Sebastian Gottschall
>>>>> <s.gottschall at dd-wrt.com> wrote:
>>>>>> i really can't believe this. if this is true the  160 mhz mode would not
>>>>>> make any sense.
>>>>>> the maximum tx / rx rate for 4x4 vht80 and 2x2 vht160 is identical. so
>>>>>> vht160 would not increase performance in any way
>>>>>
>>>>> Well, if it can also do 2x2 MU-MIMO at 160MHz then it can be a
>>>>> perfectly fine STA to a 4x4 160MHz MU-MIMO chip that can actually
>>>>> transmit 2x2 rates to different MU-MIMO peers.
>>>>>
>>>>> That's the outstanding question I have - is it like, 2x2 MU only, or
>>>>> is it say, 2 concurrently different spatial stream 2x2 MU? Ie, can you
>>>>> have 2 peers, different VHT spatial groups (or 4 peers, 1 spatial
>>>>> group each) all going at the same time?
>>>>>
>>>>> I'm .. not even sure how you're supposed to cleanly negotiate that you
>>>>> can do 4NSS in VHT80 but 2NSS in VHT160 to a peer... that only makes
>>>>> sense if you're doing lots of 1NSS and 2NSS MU-MIMO peers..
>>>>
>>>> I think using the max-rx-rate logic might could imply this, but I am not sure
>>>> many drivers fill this out properly.
>>>>
>>>> Looks like a mess waiting to happen to me.
>>>>
>>>> Even if you can do 1x1 160Mhz MU-MIMO to two stations, and I am not certain you
>>>> can since in 80Mhz you can only do a 1x1 and a 2x2 (not two 2x2).
>>>>
>>>> So, from what I know currently, 80+80 is not that useful on the 9984 NIC...
>>> never tried 80+80 since i need to enhance the channel logic alot in my firmware code to handle it. would be great enough if vht160 would work as expected and
>>> i'm not sure right now if it really works, even if the interface initialized correctly it assocs only with vht80
>>
>> Looks like it is working with the hack I posted:
>>
>> Station 04:f0:21:2e:49:65 (on wlan2)
>>     inactive time:    0 ms
>>     rx bytes:    64902998
>>     rx packets:    37918
>>     tx bytes:    64760298
>>     tx packets:    42239
>>     tx retries:    0
>>     tx failed:    0
>>     signal:      -43 dBm
>>     signal avg:    -42 dBm
>>     tx bitrate:    1053.0 MBit/s VHT-MCS 6 160MHz VHT-NSS 2
>>     rx bitrate:    1560.0 MBit/s VHT-MCS 8 160MHz short GI VHT-NSS 2
>>     authorized:    yes
>>     authenticated:    yes
>>     preamble:    long
>>     WMM/WME:    yes
>>     MFP:        no
>>     TDLS peer:    no
>>     connected time:    156 seconds
>>
>> Thanks,
>> Ben
>>
>>
> the hack you posted crashes the driver for me. i also see that this patch is based on the CT ath10k source. it doesnt apply clean to ath10k. needed to merge it
> manually

Ok, I'm in the middle of a bunch of changes to support VHT overrides to allow
disabling VHT160/80+80 in station mode, and I'll push all my changes to my
tree when I get that implemented and testing.

I've about given up on getting ath10k patches upstream, but I'll get these changes into
ath10k-ct in LEDE sometime...

If you want to post the splat, just possibly I'll have a quick idea of why it
is crashing.

Thanks,
Ben


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