MikroTik

As it turns out (viewtopic.php?t=203117#p1046670), wifi-qcom(-ac) drivers always enable 802.11b on 2.4 GHz interfaces: Basic rates are set to "1, 2, 5.5, 11" so beacons are sent at a mere 1 Mbps.
I realize that making basic rates completely customizable with the new wifi drivers might be an issue, but please provide at least an option to set the 2 GHz interface to 802.11g+ with basic rates "6, 12, 24" like already used on 5 GHz.

When fast 5 GHz is available, slow speed on 2 GHz is less of an issue. But if available airtime on 2 GHz can be improved easily, I think it should be done. Especially when there are new 2 GHz only devices like hAP ax lite.

Thank you.

+1

+1

Yes, beacon frame is more than 4x longer, especially when is set to AX.
Airtime rise from 396us to 2872us according to screenshot.

+1

With old drivers i used to set min rate to 12 for 2.4GHz and to 24 for 5GHz without any issues. Unless you use really old clients this will work.

EDIT: +1 Sorry for the missundertanding. I wanted to point that this rates worked fine and there is no reason this to not work in new drivers too.

With old drivers i used to set min rate to 12 for 2.4GHz and to 24 for 5GHz without any issues. Unless you use really old clients this will work.

This topic/feature request is about wifi-qcom(-ac) drivers. Nobody talking about "old drivers". Please.

+1

+1 for allowing us changing wireless rates in new drivers and new ax devices.

+1, I'm missing this feature as well in the wifi-qcom* packages.

And if not the complete basic rates functionality, at least the feature to retire b/g if desired.

at least the feature to retire b/g if desired.

"g" is not that important ... the 6Mbps as basic rate is also used in "n" and "ac".

"b" goes to 1Mbps, and whenever an AP with g/n sees some device transmitting "b", it also falls back to 1Mbps. (Even if the "b" device is not associating to that AP, or if the AP is set to "g/n".)

"g and n also fall back to DSSS to maintain backwards compatibility with 802.11b radios"

Without "b" we could have 4 separate 20MHz channels in 2.4GHz band in Europe. 1-5-9-13. "b" DSSS is 22MHz wide AFAIK.


Some extensive reading: https://www.cnrood.com/en/media/solutio ... _Layer.pdf

+1

whenever an AP with g/n sees some device transmitting "b", it also falls back to 1Mbps

Wait, so does this mean that mere presence of another AP set to support 802.11b (and its sending out of beacons) makes g/n APs fall back to 802.11b 1Mbps basic rate?

It's worse ... not only 802.11b supporting AP, but a station (client) with b will trigger the protection overhead:
"the presence of an IEEE 802.11b station produces a harmful chain reaction in dense
environments since neighboring BSSs also activate their protection mechanisms"

And it is quite complicated with the different implementations.

It's more than the air-time consumption of those slow rates. https://www.extremenetworks.com/resourc ... nnectivity

This here explains it in detail: https://upcommons.upc.edu/bitstream/han ... T_drac.pdf <recommended reading!>

And tells us what we should (be able to) do.

"To avoid the resulting performance degradation,
administrators of enterprise-level deployments use to ban oldest stations by configuring the basic rate set
appropriately. For example, if an AP requests mandatory support of, at least, IEEE 802 11g rates (in our
survey, only 3% of the APs), old IEEE 802.11b stations will be banned from that BSS; if that BSS is
expected to give service to IEEE 802.11b stations, the slowest rates (i.e. 1 and 2Mbps) could be excluded
from the supported rate set."

(We already did or exagerated it with the leagcy drivers.
Legacy drivers with their unfortunatly smaller max A_MPDU, hurting performance at high interface rates)

Without "b" we could have 4 separate 20MHz channels in 2.4GHz band in Europe. 1-5-9-13. "b" DSSS is 22MHz wide AFAIK.

Seconded. 802.11b-channels are too wide for a bandwidth plan with four non-overlapping channels. Please don't use 802.11b and please afford us the ability to exclude it.

Bump

Any news here? This is still an issue with 7.16.2.

+1!