* VHT 160Mhz and nss related config.
@ 2017-02-10 22:58 Ben Greear
[not found] ` <CAJ-Vmo=-JBrkmUPcYrRbARYuWv_=-MeQpPwAN_0J3v8pA5mPnw@mail.gmail.com>
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Ben Greear @ 2017-02-10 22:58 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, ath10k
So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4 MIMO at VHT80, but
it can do only 2x2 MIMO at VHT160/80+80.
When configuring a peer, we need to tell the firmware the number of spatial streams
of the peer at VHT160 and at VHT80 and lower. They are not the same value.
I cannot think of any standard way to get this information based on VHT capabilities
and such. Currently, one could just assume VHT160 NSS is 1/2 of the VHT80 NSS,
but that is unlikely to be true for all vendors.
Any ideas?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 21+ messages in thread[parent not found: <CAJ-Vmo=-JBrkmUPcYrRbARYuWv_=-MeQpPwAN_0J3v8pA5mPnw@mail.gmail.com>]
* Re: VHT 160Mhz and nss related config. [not found] ` <CAJ-Vmo=-JBrkmUPcYrRbARYuWv_=-MeQpPwAN_0J3v8pA5mPnw@mail.gmail.com> @ 2017-02-10 23:26 ` Ben Greear 0 siblings, 0 replies; 21+ messages in thread From: Ben Greear @ 2017-02-10 23:26 UTC (permalink / raw) To: Adrian Chadd; +Cc: ath10k, linux-wireless On 02/10/2017 03:23 PM, Adrian Chadd wrote: > Is it limited on both tx and rx or only one? Both, as I understand it. I think maybe we could use the max-tx-rate and max-rx-rate fields in the vht mcs info field to give user-space a clue. Thanks, Ben > > > > Adrian > > On Feb 10, 2017 2:58 PM, "Ben Greear" <greearb@candelatech.com <mailto:greearb@candelatech.com>> wrote: > > So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4 MIMO at VHT80, but > it can do only 2x2 MIMO at VHT160/80+80. > > When configuring a peer, we need to tell the firmware the number of spatial streams > of the peer at VHT160 and at VHT80 and lower. They are not the same value. > > I cannot think of any standard way to get this information based on VHT capabilities > and such. Currently, one could just assume VHT160 NSS is 1/2 of the VHT80 NSS, > but that is unlikely to be true for all vendors. > > Any ideas? > > Thanks, > Ben > > -- > Ben Greear <greearb@candelatech.com <mailto:greearb@candelatech.com>> > Candela Technologies Inc http://www.candelatech.com > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 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-11 4:22 ` Sebastian Gottschall 2017-02-11 4:37 ` Adrian Chadd 2017-02-13 7:06 ` Johannes Berg 2 siblings, 1 reply; 21+ messages in thread From: Sebastian Gottschall @ 2017-02-11 4:22 UTC (permalink / raw) To: Ben Greear, linux-wireless@vger.kernel.org, ath10k 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 Am 10.02.2017 um 23:58 schrieb Ben Greear: > So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4 MIMO > at VHT80, but > it can do only 2x2 MIMO at VHT160/80+80. > > When configuring a peer, we need to tell the firmware the number of > spatial streams > of the peer at VHT160 and at VHT80 and lower. They are not the same > value. > > I cannot think of any standard way to get this information based on > VHT capabilities > and such. Currently, one could just assume VHT160 NSS is 1/2 of the > VHT80 NSS, > but that is unlikely to be true for all vendors. > > Any ideas? > > Thanks, > Ben > -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Berliner Ring 101, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottschall@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-11 4:22 ` Sebastian Gottschall @ 2017-02-11 4:37 ` Adrian Chadd 2017-02-11 17:58 ` Ben Greear 0 siblings, 1 reply; 21+ messages in thread From: Adrian Chadd @ 2017-02-11 4:37 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: Ben Greear, linux-wireless@vger.kernel.org, ath10k 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.. -adrian > > Am 10.02.2017 um 23:58 schrieb Ben Greear: >> >> So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4 MIMO a= t >> VHT80, but >> it can do only 2x2 MIMO at VHT160/80+80. >> >> When configuring a peer, we need to tell the firmware the number of >> spatial streams >> of the peer at VHT160 and at VHT80 and lower. They are not the same >> value. >> >> I cannot think of any standard way to get this information based on VHT >> capabilities >> and such. Currently, one could just assume VHT160 NSS is 1/2 of the VHT= 80 >> NSS, >> but that is unlikely to be true for all vendors. >> >> Any ideas? >> >> Thanks, >> Ben >> > > > -- > Mit freundlichen Gr=C3=BCssen / Regards > > Sebastian Gottschall / CTO > > NewMedia-NET GmbH - DD-WRT > Firmensitz: Berliner Ring 101, 64625 Bensheim > Registergericht: Amtsgericht Darmstadt, HRB 25473 > Gesch=C3=A4ftsf=C3=BChrer: Peter Steinh=C3=A4user, Christian Scheele > http://www.dd-wrt.com > email: s.gottschall@dd-wrt.com > Tel.: +496251-582650 / Fax: +496251-5826565 > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-11 4:37 ` Adrian Chadd @ 2017-02-11 17:58 ` Ben Greear 2017-02-11 18:21 ` Sebastian Gottschall 0 siblings, 1 reply; 21+ messages in thread From: Ben Greear @ 2017-02-11 17:58 UTC (permalink / raw) To: Adrian Chadd, Sebastian Gottschall; +Cc: linux-wireless@vger.kernel.org, ath10k 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... Thanks, Ben > > > -adrian > >> >> Am 10.02.2017 um 23:58 schrieb Ben Greear: >>> >>> So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4 MIMO at >>> VHT80, but >>> it can do only 2x2 MIMO at VHT160/80+80. >>> >>> When configuring a peer, we need to tell the firmware the number of >>> spatial streams >>> of the peer at VHT160 and at VHT80 and lower. They are not the same >>> value. >>> >>> I cannot think of any standard way to get this information based on VHT >>> capabilities >>> and such. Currently, one could just assume VHT160 NSS is 1/2 of the VHT80 >>> NSS, >>> but that is unlikely to be true for all vendors. >>> >>> Any ideas? >>> >>> Thanks, >>> Ben >>> >> >> >> -- >> Mit freundlichen Grüssen / Regards >> >> Sebastian Gottschall / CTO >> >> NewMedia-NET GmbH - DD-WRT >> Firmensitz: Berliner Ring 101, 64625 Bensheim >> Registergericht: Amtsgericht Darmstadt, HRB 25473 >> Geschäftsführer: Peter Steinhäuser, Christian Scheele >> http://www.dd-wrt.com >> email: s.gottschall@dd-wrt.com >> Tel.: +496251-582650 / Fax: +496251-5826565 >> >> >> _______________________________________________ >> 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-11 17:58 ` Ben Greear @ 2017-02-11 18:21 ` Sebastian Gottschall 2017-02-11 19:38 ` Ben Greear 2017-02-13 19:56 ` Ben Greear 0 siblings, 2 replies; 21+ messages in thread From: Sebastian Gottschall @ 2017-02-11 18:21 UTC (permalink / raw) To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k 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 > > Thanks, > Ben > >> >> >> -adrian >> >>> >>> Am 10.02.2017 um 23:58 schrieb Ben Greear: >>>> >>>> So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4 >>>> MIMO at >>>> VHT80, but >>>> it can do only 2x2 MIMO at VHT160/80+80. >>>> >>>> When configuring a peer, we need to tell the firmware the number of >>>> spatial streams >>>> of the peer at VHT160 and at VHT80 and lower. They are not the same >>>> value. >>>> >>>> I cannot think of any standard way to get this information based on >>>> VHT >>>> capabilities >>>> and such. Currently, one could just assume VHT160 NSS is 1/2 of >>>> the VHT80 >>>> NSS, >>>> but that is unlikely to be true for all vendors. >>>> >>>> Any ideas? >>>> >>>> Thanks, >>>> Ben >>>> >>> >>> >>> -- >>> Mit freundlichen Grüssen / Regards >>> >>> Sebastian Gottschall / CTO >>> >>> NewMedia-NET GmbH - DD-WRT >>> Firmensitz: Berliner Ring 101, 64625 Bensheim >>> Registergericht: Amtsgericht Darmstadt, HRB 25473 >>> Geschäftsführer: Peter Steinhäuser, Christian Scheele >>> http://www.dd-wrt.com >>> email: s.gottschall@dd-wrt.com >>> Tel.: +496251-582650 / Fax: +496251-5826565 >>> >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >> > > -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Berliner Ring 101, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottschall@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-11 18:21 ` Sebastian Gottschall @ 2017-02-11 19:38 ` Ben Greear 2017-02-12 10:56 ` Sebastian Gottschall 2017-02-13 19:56 ` Ben Greear 1 sibling, 1 reply; 21+ messages in thread From: Ben Greear @ 2017-02-11 19:38 UTC (permalink / raw) To: Sebastian Gottschall, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k 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 160Mhz is really implemented as 80+80 internally it seems, so what I meant is that 160Mhz or 80+80 both have the 2x2 restriction. Stock ath10k driver doesn't set the rxnss_override, so the chip will always be forced to send 1x1 at 160Mhz, so even if it associates and works at all, it will probably not put many 160Mhz frames on air since the rate-ctrl should choose 3x3 or 4x4 80Mhz as faster speeds. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-11 19:38 ` Ben Greear @ 2017-02-12 10:56 ` Sebastian Gottschall 2017-02-12 16:05 ` Ben Greear 0 siblings, 1 reply; 21+ messages in thread From: Sebastian Gottschall @ 2017-02-12 10:56 UTC (permalink / raw) To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k Am 11.02.2017 um 20:38 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 > > 160Mhz is really implemented as 80+80 internally it seems, so what I > meant is that > 160Mhz or 80+80 both have the 2x2 restriction. since i have a older fw source. can you give me a hint where you found a indication that its just 2x2? > > Stock ath10k driver doesn't set the rxnss_override, so the chip will > always be forced > to send 1x1 at 160Mhz, so even if it associates and works at all, it > will probably not put > many 160Mhz frames on air since the rate-ctrl should choose 3x3 or 4x4 > 80Mhz as faster speeds. sounds logic > > Thanks, > Ben > > -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Berliner Ring 101, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottschall@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-12 10:56 ` Sebastian Gottschall @ 2017-02-12 16:05 ` Ben Greear 2017-02-12 20:21 ` Sebastian Gottschall 0 siblings, 1 reply; 21+ messages in thread From: Ben Greear @ 2017-02-12 16:05 UTC (permalink / raw) To: Sebastian Gottschall, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k On 02/12/2017 02:56 AM, Sebastian Gottschall wrote: > Am 11.02.2017 um 20:38 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 >> >> 160Mhz is really implemented as 80+80 internally it seems, so what I meant is that >> 160Mhz or 80+80 both have the 2x2 restriction. > since i have a older fw source. can you give me a hint where you found a indication that its just 2x2? Look for: MAX_SPATIAL_STREAMS_SUPPORTED_AT_160MHZ Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-12 16:05 ` Ben Greear @ 2017-02-12 20:21 ` Sebastian Gottschall 0 siblings, 0 replies; 21+ messages in thread From: Sebastian Gottschall @ 2017-02-12 20:21 UTC (permalink / raw) To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k Am 12.02.2017 um 17:05 schrieb Ben Greear: > > > On 02/12/2017 02:56 AM, Sebastian Gottschall wrote: >> Am 11.02.2017 um 20:38 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 >>> >>> 160Mhz is really implemented as 80+80 internally it seems, so what I >>> meant is that >>> 160Mhz or 80+80 both have the 2x2 restriction. >> since i have a older fw source. can you give me a hint where you >> found a indication that its just 2x2? > > Look for: > > MAX_SPATIAL_STREAMS_SUPPORTED_AT_160MHZ your findings where correct. frustrating. > > Thanks, > Ben > -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Berliner Ring 101, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottschall@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-11 18:21 ` Sebastian Gottschall 2017-02-11 19:38 ` Ben Greear @ 2017-02-13 19:56 ` Ben Greear 2017-02-13 21:19 ` Sebastian Gottschall 2017-02-13 22:48 ` Sebastian Gottschall 1 sibling, 2 replies; 21+ messages in thread From: Ben Greear @ 2017-02-13 19:56 UTC (permalink / raw) To: Sebastian Gottschall, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k 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 -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-13 19:56 ` Ben Greear @ 2017-02-13 21:19 ` Sebastian Gottschall 2017-02-13 22:48 ` Sebastian Gottschall 1 sibling, 0 replies; 21+ messages in thread From: Sebastian Gottschall @ 2017-02-13 21:19 UTC (permalink / raw) To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k 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 cool. let me check it on my devices > > -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Berliner Ring 101, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottschall@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 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 1 sibling, 1 reply; 21+ messages in thread From: Sebastian Gottschall @ 2017-02-13 22:48 UTC (permalink / raw) To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k 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 -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Berliner Ring 101, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottschall@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-13 22:48 ` Sebastian Gottschall @ 2017-02-13 23:12 ` Ben Greear 2017-02-14 10:19 ` Sebastian Gottschall 0 siblings, 1 reply; 21+ messages in thread From: Ben Greear @ 2017-02-13 23:12 UTC (permalink / raw) To: Sebastian Gottschall, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-13 23:12 ` Ben Greear @ 2017-02-14 10:19 ` Sebastian Gottschall 0 siblings, 0 replies; 21+ messages in thread From: Sebastian Gottschall @ 2017-02-14 10:19 UTC (permalink / raw) To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k now the test result. yes. it assocs with VHT160 SGI in my case. but performance is as expected identical to VHT80 Am 14.02.2017 um 00:12 schrieb 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@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 > > -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Berliner Ring 101, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottschall@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 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-11 4:22 ` Sebastian Gottschall @ 2017-02-13 7:06 ` Johannes Berg 2017-02-13 19:21 ` Ben Greear 2 siblings, 1 reply; 21+ messages in thread From: Johannes Berg @ 2017-02-13 7:06 UTC (permalink / raw) To: Ben Greear, linux-wireless@vger.kernel.org, ath10k On Fri, 2017-02-10 at 14:58 -0800, Ben Greear wrote: > So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4 > MIMO at VHT80, but > it can do only 2x2 MIMO at VHT160/80+80. > > When configuring a peer, we need to tell the firmware the number of > spatial streams > of the peer at VHT160 and at VHT80 and lower. They are not the same > value. > > I cannot think of any standard way to get this information based on > VHT capabilities and such. Currently, one could just assume VHT160 > NSS is 1/2 of the VHT80 NSS, but that is unlikely to be true for all > vendors. This was recently added to the VHT capabilities in the spec, see Table 9-250 in 802.11-2016. johannes ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 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 0 siblings, 2 replies; 21+ messages in thread From: Ben Greear @ 2017-02-13 19:21 UTC (permalink / raw) To: Johannes Berg, linux-wireless@vger.kernel.org, ath10k On 02/12/2017 11:06 PM, Johannes Berg wrote: > On Fri, 2017-02-10 at 14:58 -0800, Ben Greear wrote: >> So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4 >> MIMO at VHT80, but >> it can do only 2x2 MIMO at VHT160/80+80. >> >> When configuring a peer, we need to tell the firmware the number of >> spatial streams >> of the peer at VHT160 and at VHT80 and lower. They are not the same >> value. >> >> I cannot think of any standard way to get this information based on >> VHT capabilities and such. Currently, one could just assume VHT160 >> NSS is 1/2 of the VHT80 NSS, but that is unlikely to be true for all >> vendors. > > This was recently added to the VHT capabilities in the spec, see Table > 9-250 in 802.11-2016. > > johannes > I don't have that spec...maybe you could post a patch that adds that flag and/or other fields to the appropriate header files? I can attempt to add support to ath10k after that... Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-13 19:21 ` Ben Greear @ 2017-02-13 19:27 ` Adrian Chadd 2017-02-13 19:37 ` Johannes Berg 1 sibling, 0 replies; 21+ messages in thread From: Adrian Chadd @ 2017-02-13 19:27 UTC (permalink / raw) To: Ben Greear; +Cc: Johannes Berg, linux-wireless@vger.kernel.org, ath10k .. or give us a legit way to acquire the 2016 spec? :) Curious implementers want to know! -a On 13 February 2017 at 11:21, Ben Greear <greearb@candelatech.com> wrote: > On 02/12/2017 11:06 PM, Johannes Berg wrote: >> >> On Fri, 2017-02-10 at 14:58 -0800, Ben Greear wrote: >>> >>> So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4 >>> MIMO at VHT80, but >>> it can do only 2x2 MIMO at VHT160/80+80. >>> >>> When configuring a peer, we need to tell the firmware the number of >>> spatial streams >>> of the peer at VHT160 and at VHT80 and lower. They are not the same >>> value. >>> >>> I cannot think of any standard way to get this information based on >>> VHT capabilities and such. Currently, one could just assume VHT160 >>> NSS is 1/2 of the VHT80 NSS, but that is unlikely to be true for all >>> vendors. >> >> >> This was recently added to the VHT capabilities in the spec, see Table >> 9-250 in 802.11-2016. >> >> johannes >> > > I don't have that spec...maybe you could post a patch that adds that flag > and/or other fields to the appropriate header files? I can attempt to > add support to ath10k after that... > > > Thanks, > Ben > > -- > Ben Greear <greearb@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 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 1 sibling, 1 reply; 21+ messages in thread From: Johannes Berg @ 2017-02-13 19:37 UTC (permalink / raw) To: Ben Greear, linux-wireless@vger.kernel.org, ath10k > > This was recently added to the VHT capabilities in the spec, see > > Table 9-250 in 802.11-2016. > I don't have that spec...maybe you could post a patch that adds that > flag and/or other fields to the appropriate header files? I can > attempt to add support to ath10k after that... We're planning to, but it's not the most important thing on my list right now ... I'll check where that's at now. I can't even easily explain it, since it's really complicated. johannes ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-13 19:37 ` Johannes Berg @ 2017-02-13 19:42 ` Ben Greear 2017-02-13 19:51 ` Johannes Berg 0 siblings, 1 reply; 21+ messages in thread From: Ben Greear @ 2017-02-13 19:42 UTC (permalink / raw) To: Johannes Berg, linux-wireless@vger.kernel.org, ath10k On 02/13/2017 11:37 AM, Johannes Berg wrote: > >>> This was recently added to the VHT capabilities in the spec, see >>> Table 9-250 in 802.11-2016. > >> I don't have that spec...maybe you could post a patch that adds that >> flag and/or other fields to the appropriate header files? I can >> attempt to add support to ath10k after that... > > We're planning to, but it's not the most important thing on my list > right now ... I'll check where that's at now. > > I can't even easily explain it, since it's really complicated. So, think it is worthwhile to use the max-rx-rate as a proxy until the 'real' spec is implemented? If 2x2 160Mhz is super complicated, and yields no useful throughput improvement, then likely it will be a long time before someone implements it properly I'd guess. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: VHT 160Mhz and nss related config. 2017-02-13 19:42 ` Ben Greear @ 2017-02-13 19:51 ` Johannes Berg 0 siblings, 0 replies; 21+ messages in thread From: Johannes Berg @ 2017-02-13 19:51 UTC (permalink / raw) To: Ben Greear, linux-wireless@vger.kernel.org, ath10k On Mon, 2017-02-13 at 11:42 -0800, Ben Greear wrote: > On 02/13/2017 11:37 AM, Johannes Berg wrote: > > > > > > This was recently added to the VHT capabilities in the spec, > > > > see > > > > Table 9-250 in 802.11-2016. > > > I don't have that spec...maybe you could post a patch that adds > > > that > > > flag and/or other fields to the appropriate header files? I can > > > attempt to add support to ath10k after that... > > > > We're planning to, but it's not the most important thing on my list > > right now ... I'll check where that's at now. > > > > I can't even easily explain it, since it's really complicated. > > So, think it is worthwhile to use the max-rx-rate as a proxy > until the 'real' spec is implemented? If 2x2 160Mhz is super > complicated, and yields no useful throughput improvement, then likely > it will be a long time before someone implements it properly I'd > guess. I don't know, I haven't really followed that discussion. I don't think implementing the spec here will be really complicated, there are just a bunch of cases to consider when parsing the VHT capabilities. I won't do anything with max rate in mac80211, and I doubt you really should implement any workarounds for not having the spec here in the driver itself. johannes ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-02-14 10:19 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).