All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Gottschall <s.gottschall@dd-wrt.com>
To: Ben Greear <greearb@candelatech.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: Sun, 12 Feb 2017 11:56:03 +0100	[thread overview]
Message-ID: <159ba156-cf2d-db0d-a6af-2557b9bfa6b6@dd-wrt.com> (raw)
In-Reply-To: <02b7f70a-7da2-f2e4-8904-bdffc3ca90a1@candelatech.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Gottschall <s.gottschall@dd-wrt.com>
To: Ben Greear <greearb@candelatech.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: Sun, 12 Feb 2017 11:56:03 +0100	[thread overview]
Message-ID: <159ba156-cf2d-db0d-a6af-2557b9bfa6b6@dd-wrt.com> (raw)
In-Reply-To: <02b7f70a-7da2-f2e4-8904-bdffc3ca90a1@candelatech.com>

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


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

  reply	other threads:[~2017-02-12 10:56 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-10 22:58 VHT 160Mhz and nss related config Ben Greear
2017-02-10 22:58 ` Ben Greear
     [not found] ` <CAJ-Vmo=-JBrkmUPcYrRbARYuWv_=-MeQpPwAN_0J3v8pA5mPnw@mail.gmail.com>
2017-02-10 23:26   ` Ben Greear
2017-02-10 23:26     ` Ben Greear
2017-02-11  4:22 ` Sebastian Gottschall
2017-02-11  4:22   ` Sebastian Gottschall
2017-02-11  4:37   ` Adrian Chadd
2017-02-11  4:37     ` Adrian Chadd
2017-02-11 17:58     ` Ben Greear
2017-02-11 17:58       ` Ben Greear
2017-02-11 18:21       ` Sebastian Gottschall
2017-02-11 18:21         ` Sebastian Gottschall
2017-02-11 19:38         ` Ben Greear
2017-02-11 19:38           ` Ben Greear
2017-02-12 10:56           ` Sebastian Gottschall [this message]
2017-02-12 10:56             ` Sebastian Gottschall
2017-02-12 16:05             ` Ben Greear
2017-02-12 16:05               ` Ben Greear
2017-02-12 20:21               ` Sebastian Gottschall
2017-02-12 20:21                 ` Sebastian Gottschall
2017-02-13 19:56         ` Ben Greear
2017-02-13 19:56           ` Ben Greear
2017-02-13 21:19           ` Sebastian Gottschall
2017-02-13 21:19             ` Sebastian Gottschall
2017-02-13 22:48           ` Sebastian Gottschall
2017-02-13 22:48             ` Sebastian Gottschall
2017-02-13 23:12             ` Ben Greear
2017-02-13 23:12               ` Ben Greear
2017-02-14 10:19               ` Sebastian Gottschall
2017-02-14 10:19                 ` Sebastian Gottschall
2017-02-13  7:06 ` Johannes Berg
2017-02-13  7:06   ` Johannes Berg
2017-02-13 19:21   ` Ben Greear
2017-02-13 19:21     ` Ben Greear
2017-02-13 19:27     ` Adrian Chadd
2017-02-13 19:27       ` Adrian Chadd
2017-02-13 19:37     ` Johannes Berg
2017-02-13 19:37       ` Johannes Berg
2017-02-13 19:42       ` Ben Greear
2017-02-13 19:42         ` Ben Greear
2017-02-13 19:51         ` Johannes Berg
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=159ba156-cf2d-db0d-a6af-2557b9bfa6b6@dd-wrt.com \
    --to=s.gottschall@dd-wrt.com \
    --cc=adrian@freebsd.org \
    --cc=ath10k@lists.infradead.org \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.