mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-13 10:02:38 +00:00
6851341a33
Ok, yeah, the commit title is a bit misleading. This has to do with CDD (cyclic delay diversity) - how this and later wifi hardware transmits lower rates over more antennas. Eg, if you're transmitting legacy 11abg rates on 2 or 3 antennas, you COULD just send them all at the same time or you could delay each by tens/hundreds of nanoseconds to try and get some better diversity characteristics. However, this has a fun side effect - the antenna pattern is no longer a bunch of interacting dipoles, but are a bunch of interacting dipoles plus a bunch of changing phases. And it's frequency dependent - 50-200nS is not exactly the same fraction of a wavelength across all of 2GHz or 5GHz! Thus the power spectral density and maximum directional gain that you're effectively getting is not .. well, as flat as it once was. For more information, look up FCC/OET 13TR1003 in the FCC technical report database. It has pretty graphics and everything. Anyway, the problem lies thusly - the CDD code just subtracts another 3dB or 5dB for the lower rates based on transmit antenna configuration. However, it's not done based on operating configuration and it doesn't take into account how far from any regulatory limits the hardware is at. It also doesn't let us do things like transmit legacy rates and frames on a single antenna without losing up to 5dB when we absolutely don't need to in that case (there's no CDD used when one antenna is used!) This shows up as the hardware behaving even worse for longer distance links at 20MHz because, well, those are the exact rates losing a bunch more transmit power. * For lower power NICs (ie the majority of what is out there!) it's highly unlikely we're going to hit anywhere near the PSD limits. * It's doing it based on the existing limits from the CTL table (conformance testing limits) - this isn't the regulatory max! It's what the NIC is allowed to put out in each frequency and rate configuration! So things like band edges, power amplifier behaviour and maximum current draw apply here. Blindly subtracting 3 to 5dB from /this/ value is /very/ conservative.. * /and/ ath9k just plainly doesn't do any of this at all. So, for now disable it and get the TX power back, thus matching what ath9k in Linux is doing. If/once I get some more cycles I'll look at making it a bit more adaptive and really only kick in if we're a few dB away from hard regulatory limits. Tested: * AR9344 (2GHz + SoC, 2x2 configuration) - AP and STA modes * QCA9580 (5GHz 2x2 and 3x3 configurations) - AP and STA modes |
||
|---|---|---|
| .. | ||
| alpine-hal | ||
| ck | ||
| cloudabi | ||
| dev | ||
| edk2 | ||
| ena-com | ||
| ipfilter/netinet | ||
| libb2 | ||
| libfdt | ||
| libnv | ||
| libsodium | ||
| ncsw | ||
| ngatm | ||
| octeon-sdk | ||
| rdma/krping | ||
| v4l | ||
| vchiq/interface | ||
| x86emu | ||
| xz-embedded | ||
| zlib | ||
| zstd | ||