Don't mean to steal your thread here, but since it's being discussed--
is there something that can be done to provide more accurate/precise
data? Use of the default is widespread so not a reason to hold back
the patch imo, but with a proposed pcap-ng capture information block
they would become more accessible and maybe there will be increased
interest in real values.
Anyway to fill out IEEE80211_RADIOTAP_DBM_ANT{SIGNAL,NOISE}?
I recall from another thread that there isn't currently periodic
calibration but the floor could change with environment too.
On Tue, Dec 17, 2019 at 8:05 PM Sebastian Gottschall
<s.gottschall@xxxxxxxxxxxxxxx> wrote:
>
>
> Am 18.12.2019 um 03:37 schrieb Ben Greear:
> >
> >
> > 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.
> yeah. right. sorry i was just looking at total signal sum which uses
> rssi_comb_ht
> >
> >
> >> 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.
> that will not work. you compare different chipsets and depending on the
> implementation by the card vendor
> rf sensitivity can be very diffent. the same goes for output power. some
> vendors are using additional rf amps
> for enhancing output power (ubiquiti is best example here). this these
> amps also may have influence to sensitivity.
> on these cards you set 10 db output power, but in fact it outputs 18 db.
> so there is a bias offset on these cards or devices. (the offset is
> depending on the device model)
>
> what you measure is what the chip receives, but not what was lost on the
> pcb layout. (or was even generated in case of noise)
> and when it comes to calibration data. correct would be if each
> individual card is calibrated before shipment. in reality manufactures
> are doing calibration on a single reference card and clone it on all
> following cards to save time. the result depends on day or week of
> production
> and current position of the moon and sun. errors of +- 2 db are common
> here. (this is not a fact for all card or device vendors)
>
> >
> > 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?
> yes. this is modulation related. as higher the rate goes as lower the
> power will be. thats princible of QAM.
> and the rate control itself isnt signal but error rate based. so high
> packet loss triggers the rate control to lower the rate which results
> in increased output power and vice versa. but as mentioned. at card
> startup a noise floor calibration starts which may succeed or fail.
> if it succeeds it will turn into a long delay phase. so cyclic
> calibration. the calibration time is exactly 30 seconds (minimum) and if
> it fails it can
> exceed to 60 seconds. after that time it will sleep for 300 seconds and
> will check for recalibration conditions. (there are rules like high
> noise floor changes etc.)
> a recalibration is also triggered at channel changes and if chipset
> temperature changes at a certain level.
> from what i have seen the procedure in the qca9880 firmware is exactly
> the same as in ath9k.
> anyway. while this calibration is running, the signal and noise floor
> might be unstable or even bogus until this is finished and rate control
> might not be optimal
> under stress conditions like long range links with low signals. with
> standard wifi usage you should not notice it that much since signal to
> noise ratio is high enough anyway
>
>
> >
> > 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@xxxxxxxxxxxxxxxxxxx/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
> >>>
> >>
> >
