śr., 21 cze 2023 o 18:12 Johannes Berg <johannes@xxxxxxxxxxxxxxxx> napisał(a):
>
> On Wed, 2023-06-21 at 07:48 -0700, Ben Greear wrote:
> > On 6/21/23 4:57 AM, Johannes Berg wrote:
> > > On Tue, 2023-06-20 at 06:19 -0700, Ben Greear wrote:
> > > > On 6/20/23 3:03 AM, gregory.greenman@xxxxxxxxx wrote:
> > > > > From: Johannes Berg <johannes.berg@xxxxxxxxx>
> > > > >
> > > > > If a discrete NIC is connected to a PCIe link hat isn't at least
> > > > > Gen3 (8.0 GT/s), then we cannot sustain 320 MHz traffic, so remove
> > > > > that from EHT capabilities in that case.
> > > > >
> > > > > While at it, also move setting 320 MHz beamformee to the right
> > > > > place in the code so it's not set while not supporting 320 MHz.
> > > >
> > > > Is there not an advantage to allowing 320Mhz for longer distance connections
> > > > where signal is relatively weak, so over-all tput would easily fit in lesser
> > > > pcie bus? Especially on 6E band where the US regdom allows more over-all power
> > > > when using wider bandwidths?
> > > >
> > >
> > > I actually don't know. This surely isn't ideal, but it's the only way to
> > > really force the AP to not send too much than the NIC can pass out, and
> > > it gets unhappy if it can't.
> >
> > So this is to work around hardware/firmware bug in NIC? If so, that should
> > be mentioned.
>
> I'm not sure that's really even a _bug_, it just doesn't have a lot of
> buffer space inside of it; as far as I know, given how the HW
> architecture works, the FW doesn't have a lot of options.
>
> > I have heard in the past that higher bandwidth works better than higher NSS
> > in a lot of cases, so if HW/FW can be made to deal with floods in unlikely
> > case that the RF is perfect enough to saturate the PCI bus, then I think you
> > should allow 320Mhz even on slower PCI bus configurations.
>
> Right. I don't think it's likely that the firmware will do, but hey, I
> can let them know :)
>
Could we revert this one?
In my noisy env after disarm this check, still get better results for
320 than 160:
janusz@e850:~/github/wifi_tests/tests/remote$ ./run-tests.py -c
cfg-janusz.py -d bpi-r4 -r be200 -t connect_6g_tp
DUT: bpi-r4
REF: be200
RUN check_devices
PASS
START - connect_6g_tp (1/1)
PASS (
(6g/1/EHT320): ping pkt loss ap->sta: 0%, sta->ap: 0%
(6g/1/EHT320): ap->sta: 1453 Mbits/sec, sta->ap: 2097 Mbits/sec
) - 69.055398s
janusz@e850:~/github/wifi_tests/tests/remote$ ./run-tests.py -c
cfg-janusz.py -d bpi-r4 -r be200 -t connect_6g_tp
DUT: bpi-r4
REF: be200
RUN check_devices
PASS
START - connect_6g_tp (1/1)
PASS (
(6g/1/EHT160): ping pkt loss ap->sta: 0%, sta->ap: 0%
(6g/1/EHT160): ap->sta: 1266 Mbits/sec, sta->ap: 1706 Mbits/sec
) - 69.324334s
janusz@e850:~/github/wifi_tests/tests/remote$
BR
Janusz
