mt76: chipset limitations

[CodeFetch]

As nbd168 told me last year, these chipsets seem to be unable to handle transmit scheduling. ath9k chipsets can use next_tbtt in conjunction with a special "release on beacon" queue to transmit a packet with a granularity of < 1 ms. ath10k chipsets are also able to do this, but require a modified firmware. Qualcomm offers one to sign a NDA for open source development under a special programme which would give one the possibility to write such a firmware for ath10k. You may know these features are being used by Ubiquity AirMax and TP-Link Pharos to implement TDMA. For mesh networks to be scalable one needs these features, too, because it mitigates the hidden node problem. It is defined in the 802.11s standard and called MCCA. It has not been implemented, because the company which was hired to help implementing 802.11s in the kernel wasn't paid for doing it and thus offered it to big companies which never published it open source. Long story short:

In the future we may have the capability to make use of MCCA which will make mesh networks become what some people already advertise: robust and scalable, but the cheap mt76 chipsets likely won't support it and be a bottleneck for the whole mesh network they are being used in. Thus as Gluon now has support for some mt76 devices, I think we should make communities aware that these devices are super cheap, but probably not as sustainable as ath9/10k devices for urban mesh networks, by adding a note to all mt76 devices on the supported devices page.

[blocktrron]

Honestly, i don't like putting up a warning for a limitation we currently not have, given the fact we don't even know if we will ever be able to make use of this feature for the broadest range of devices.

Don't get me wrong, i would like to see this implemented. But in regards to wireless drivers we are already in the state of making compromises on each end if we want to move beyond 802.11n. I also see the sustainability point with a mixed feeling, given the fact mt76 targets standards which are already 2 generations behind.

[CodeFetch]

@blocktrron I understand your points and have thought about them before, too. People still recommend using 5 GHz for meshing. That recommendation was from a time where there was no widespread 5 GHz support and the 5 GHz frequencies were not that much occupied. 2.4 GHz has better propagation characteristics and 2.4 GHz is near the point where there won't be vast improvements in the next years for our purposes. What I want to say is that 2.4 GHz devices will be fine the next years and the ath9k chipset is future proof contrary to the mt76. I'm already working on getting funding for a mainline kernel MCCA implementation. Many organisations have an interest in getting this merged. Chances are good that we see this coming up in the next few years. Just think of Ubiquity - they would switch to mt76 if they would think it has the same capabilities like ath9/10k, but it's a chip for low budget consumer routers. If you like, compare a WDR4900 with it's overdesigned MPC to a 841N with it's cheap MIPS processor. TP-Link used an enterprise CPU for a consumer router, because there was nothing cheaper on the market, that would fit their needs. It's the same with ath9/10k chips used by TP-Link. They don't switch to mt76 because these chips are better, but because they are cheaper and still fit their needs. For rural areas where it is unlikely that there will be big wifi mesh clouds or where people still talk to each other and are able to plan the network, switch channels etc. mt76 will be fine, but if you just want the routers to build such a network autonomously which doesn't break with too many nodes, you need MCCA.

If you ask yourself why there won't be vast improvements for 2.4 GHz:

• The presumption we took for granted that the technology will improve rapidly constantly does no longer apply. WiFi has come to a point where it performs better than the requirements of average broadband connections for the next years. The target market is not Europe and America anymore, but Asia and Africa. While a mt76 router costs $5 on theses continents in Europe they cost more than $20, because consumers don't realize the price drop in manufacturing costs.
• For high-bandwidth consumer requirements the next steps of development are already known: Using a broader channel width and improving spectral efficiency on 5 GHz channels Making use of phased-array antennas and dynamic low power transmissions for delivering content in the near-field (because client devices are ordinarily under 20 m away from their access points in consumer setups and the densitiy of devices in blocks of flats is the problem chip manufacturers try to solve at the moment)
• The planned improvements for 2.4 GHz are to just aggregate it with 5 GHz channels and improve spectral efficiency like AC -> this will improve the bandwidth in the near-field, but not that much on distance. The reason why AC performs so good on Ubiquity AirMax devices compared to legacy 802.11n is because they use cross polarized antennas. With all antennas being vertically polarized on consumer routers the improvements mostly apply to the near-field only.

[CodeFetch]

Honestly, i don't like putting up a warning for a limitation we currently not have

We have this limitation likely in hardware. Chances are near zero that this chipset will ever support transmit scheduling.

given the fact we don't even know if we will ever be able to make use of this feature for the broadest range of devices.

We would have this feature at least for ath9k as I'm planning it for more than two years now. And support for ath10k is only a monetary question (to get the needed features done in candelatech firmware). But at the moment I don't really feel willing to contribute it open-source, as I don't see that Gluon goes into the right direction at the moment. Every router in the mesh cloud that does not support frame scheduling will be an interferer. That is worth a note.

Why do I feel Gluon does not go into the right direction? What we always wanted is to have more contributors and now we have them. They do a lot of work, that nobody sees until it is being merged. Their code quality might not be what we are used to by e.g. NeoRaider, but it's all blocked and nobody here is helping them to just get it merged. Most commits at the moment are just "Update packages/update OpenWrt" etc. Of course that needs to be done, but that's no progress. Instead we implement features that will make more problems than they solve just because the people that commit them are the ones who commit "Update packages"... The only accepted way of communication is IRC. I don't have time for IRC and if I'm showing a touch of emotionality or tell a home truth here I get thumb down emojis. It's like showing someone a middle finger on Github.

Haters gonna hate.

[rotanid]

half of your comment doesn't belong in this issue here, maybe voice your concerns over the mailing list. (maybe also other github issues of yours would be better suited for the mailing list, as this repository is mostly about the code)

[CodeFetch]

I've looked at the mt76 registers and I'm pretty sure that there is a workaround for mt76 chipsets to enable transmit scheduling that nbd was not aware of. I'm closing this for now.