From: Ben Greear <greearb@candelatech.com>
To: Sebastian Gottschall <s.gottschall@newmedia-net.de>,
Tom Psyborg <pozega.tomislav@gmail.com>
Cc: linux-wireless@vger.kernel.org,
ath10k <ath10k@lists.infradead.org>,
Justin Capella <justincapella@gmail.com>
Subject: Re: [PATCH] ath10k: Per-chain rssi should sum the secondary channels
Date: Tue, 17 Dec 2019 18:37:33 -0800 [thread overview]
Message-ID: <8eae96cd-a94e-abc1-4750-73f931d657d6@candelatech.com> (raw)
In-Reply-To: <5e3f22d1-b8ba-d756-a15c-1e7ae56c1dad@newmedia-net.de>
On 12/17/2019 06:12 PM, Sebastian Gottschall wrote:
> i dont know what you want to compare here.
>
> 1. you compare 2 different wifi chipsets. both have different sensititivy and overall output power spec
>
> 2. both have different amount of antenna chains. which does make a difference in input sensitivity
>
> 3. the patch ben made has no effect on qca9880 chipsets. it only takes effect on 10.4 based chipsets like 9984
The part of my patch that sums secondary frequencies should apply to wave-1 as well, but I have
not verified that yet.
> about noise floors in general. noise floors of -108 are bogus. there is a physical limit a noise level can be.
> since drivers like ath9k are doing a cyclic calibration, the noise value might indeed change. but this calibration is
> not running in realtime. its cyclic. i'm not aware if chipsets like qca988x are going the same way, but since qca988x
> has sime similaries with ath9k chipsets unlike the newer 9984 variants, it could be. the 30 seconds mentioned
> in the bug report fits to my expectations of the early noisefloor calibration which has a short delay and after success
> turning to use a long delay. anyway. in this early calibration phase signals might change and will stabilize after. this isnt a issue
> since your connection will work anyway even if it might take a little bit longer if you have poor signal levels
>
> @ben. am i wrong or what do think?
I don't know enough about how the noise floor calculations are done or how the apply to settings
to know the answer.
I will be happy in general if ath10k wave-1, wave-2, and ath9k report similar RSSI for similar
setups.
If you look at the tx-rate-power table in ath10k, for instance, you can see different MCS are transmitted
at different signal levels. So, some change from initial conditions might be because higher MCS is
being transmitted after rate-ctrl scales up?
Lots of moving parts...
Thanks,
Ben
>
> Sebastian
>
> Am 18.12.2019 um 00:37 schrieb Tom Psyborg:
>> also noticed now that the noise floor changes with signal strength as
>> described in this bug report:
>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg11553.html
>>
>> after wifi restart
>>
>> iwinfo:
>>
>> signal: -59dBm noise: -108dBm
>>
>> then goes to
>>
>> signal: -52dBm noise: -103dBm
>>
>> and finally drops to
>>
>> signal: -59dBm noise: -103dBm
>>
>
--
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:[~2019-12-18 2:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 22:07 [PATCH] ath10k: Per-chain rssi should sum the secondary channels greearb
2019-12-17 12:02 ` Sebastian Gottschall
2019-12-17 12:32 ` Sebastian Gottschall
2019-12-17 15:05 ` Ben Greear
2019-12-17 15:58 ` Sebastian Gottschall
2019-12-17 16:23 ` Justin Capella
2019-12-17 17:38 ` Ben Greear
2019-12-17 18:29 ` Tom Psyborg
2019-12-17 18:35 ` Adrian Chadd
2019-12-17 18:35 ` Ben Greear
2019-12-17 23:08 ` Tom Psyborg
2019-12-17 23:37 ` Tom Psyborg
2019-12-17 23:43 ` Ben Greear
2019-12-18 2:12 ` Sebastian Gottschall
2019-12-18 2:37 ` Ben Greear [this message]
2019-12-18 4:05 ` Sebastian Gottschall
2019-12-18 8:05 ` Justin Capella
2019-12-18 9:10 ` Sebastian Gottschall
2019-12-18 12:59 ` Ben Greear
2019-12-18 18:59 ` Sebastian Gottschall
2019-12-18 11:48 ` Tom Psyborg
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=8eae96cd-a94e-abc1-4750-73f931d657d6@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.org \
--cc=justincapella@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=pozega.tomislav@gmail.com \
--cc=s.gottschall@newmedia-net.de \
/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