From: Ben Greear <greearb@candelatech.com>
To: Sebastian Gottschall <s.gottschall@dd-wrt.com>,
Adrian Chadd <adrian@freebsd.org>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
ath10k <ath10k@lists.infradead.org>
Subject: Re: VHT 160Mhz and nss related config.
Date: Mon, 13 Feb 2017 15:12:40 -0800 [thread overview]
Message-ID: <58A23D68.5070507@candelatech.com> (raw)
In-Reply-To: <f6d4b239-03af-976b-0c97-e7a5858f00da@dd-wrt.com>
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@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@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2017-02-13 23:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-10 22:58 VHT 160Mhz and nss related config Ben Greear
[not found] ` <CAJ-Vmo=-JBrkmUPcYrRbARYuWv_=-MeQpPwAN_0J3v8pA5mPnw@mail.gmail.com>
2017-02-10 23:26 ` Ben Greear
2017-02-11 4:22 ` Sebastian Gottschall
2017-02-11 4:37 ` Adrian Chadd
2017-02-11 17:58 ` Ben Greear
2017-02-11 18:21 ` Sebastian Gottschall
2017-02-11 19:38 ` Ben Greear
2017-02-12 10:56 ` Sebastian Gottschall
2017-02-12 16:05 ` Ben Greear
2017-02-12 20:21 ` Sebastian Gottschall
2017-02-13 19:56 ` Ben Greear
2017-02-13 21:19 ` Sebastian Gottschall
2017-02-13 22:48 ` Sebastian Gottschall
2017-02-13 23:12 ` Ben Greear [this message]
2017-02-14 10:19 ` Sebastian Gottschall
2017-02-13 7:06 ` Johannes Berg
2017-02-13 19:21 ` Ben Greear
2017-02-13 19:27 ` Adrian Chadd
2017-02-13 19:37 ` Johannes Berg
2017-02-13 19:42 ` Ben Greear
2017-02-13 19:51 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58A23D68.5070507@candelatech.com \
--to=greearb@candelatech.com \
--cc=adrian@freebsd.org \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=s.gottschall@dd-wrt.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox