It's not that I complain on wireless capabilities of mikrotik gear. It's kind of observation I made. About year ago after I got dissapointed by 802.11ac support from mikrotik I decided to use other producer equipment. The other one that gave me so much enjoyment to work with. But lately I was forced to upgrade some older links, and gave mikrotik one shot more.
Dynadish 802.11ac met my expectations. I was very happy to see nicely working ptp on new software 6.30.4. after few weeks I decided to upgrade other AP, mostly omnitiks. and here we are, what is wrong with.... multipoint mode?? It's a disaster! after day or two it eventually stops passing traffic to clients. neither auto nor 2ms mode helped. Omnitik AP, 12 apc connected, subscribers up to 16mbps, wireless data rate 39-78-90 some with dual polarization even 180mbps.
on the client side speedtest.net shows...3mbps and significant loss of packets. jitter is over reasonable range.
channel under spectral scan is totally clear.

I have complained about NV2 problems as much as anyone. I have notices however some improvement when using the wireless-cm package. You need to disable it from using cap and you push button authentication but i am seeing more stability and better tcp speeds. However The biggest issue i still see is actual throughput. On 802.11 and Routers 6.33 I do see fantastic speeds under 802.11(They did a update to the wireless-cm2 package. I don't understand why they can't bring these improvements to NV2.

I have complained about NV2 problems as much as anyone. I have notices however some improvement when using the wireless-cm package. You need to disable it from using cap and you push button authentication but i am seeing more stability and better tcp speeds. However The biggest issue i still see is actual throughput. On 802.11 and Routers 6.33 I do see fantastic speeds under 802.11(They did a update to the wireless-cm2 package. I don't understand why they can't bring these improvements to NV2.

I guess it is a HW limitation. The CPU is to weak to handle nv2 at higher data rates and higher number of cpes. Plain 802.11 is handled by the wireless part of the chipset. This wifi chipsets are not designed with a TDMA protocol in mind. For a chipmanufacterer like Atheros the numbers selled to WISP-Industry are neglectable compared to Laptop/PC Market. So MT would have to do some work at HW-Level to improve this. They still did not take this plunge (You have to spend a lot of money to do chipdesign) with the risk loosing the wireless part of their wisp business. For me it looks like they wait until Atheros delivers something better suited.

I've just reconfigured my PtMP setup from nv2 to plain 802.11ac, and it seems to work better now (tried nstreme too, but it also had issues like disconnecting frequently). Strangely enough, btest tcp results with nv2 seem significantly better than real speedtest.net results (that's what customers care about) - what's that, detecting when it's being tested like VW TDI cars?

But, don't the AC radios have their own separate CPU and firmware to offload the main CPU (unlike N radios)? Perhaps the TDMA protocol could take advantage of it, possibly at the cost of backwards compatibility with older radios? My setup is all new AC radios in clean 6GHz licensed spectrum (out of necessity, as 5GHz is already saturated), so why not make a new TDMA protocol specifically for AC radios if abandoning backwards compatibility helps make it work better.

One of the key differences that accounts for this is that the Ookla/Speedtest tools utilize multiple TCP connections to collect the measurement data which is key to avoiding the receive window limitation

I've just reconfigured my PtMP setup from nv2 to plain 802.11ac, and it seems to work better now (tried nstreme too, but it also had issues like disconnecting frequently). Strangely enough, btest tcp results with nv2 seem significantly better than real speedtest.net results (that's what customers care about) - what's that, detecting when it's being tested like VW TDI cars?

But, don't the AC radios have their own separate CPU and firmware to offload the main CPU (unlike N radios)? Perhaps the TDMA protocol could take advantage of it, possibly at the cost of backwards compatibility with older radios? My setup is all new AC radios in clean 6GHz licensed spectrum (out of necessity, as 5GHz is already saturated), so why not make a new TDMA protocol specifically for AC radios if abandoning backwards compatibility helps make it work better.

When you run btest, you're probably running several simultaneous TCP flow. When you run speedtest, just one stream is used, and results are lower

AC Radios do not have supporting CPUs to do TDMA. MT has to use the Atheros CPU of the chipset. There are Vendors who do HW-Modifikations to offload the CPU or to add GPS. This is what MT has to do to compete in WISP market. For home/indoor AP use this is not neccesary as this is plain 802.11.

AC Radios do not have supporting CPUs to do TDMA. MT has to use the Atheros CPU of the chipset. There are Vendors who do HW-Modifikations to offload the CPU or to add GPS. This is what MT has to do to compete in WISP market. For home/indoor AP use this is not neccesary as this is plain 802.11.

Well, but:
- UBNT M5 radios (ath9k) can do TDMA without an extra CPU, and while not perfect, they work reasonably well (except GPS which doesn't)
- AC radios (ath10k) do have an extra CPU running separate wireless firmware, perhaps that firmware could be modified to help TDMA on these radios

I've been running mostly UBNT M5 radios so far, but as 5GHz is getting crowded (too many competitors in the area), and UBNT are getting too paranoid about regulatory issues (limiting channels, forcing DFS etc.), so I decided to give MT AC a try for the new licensed 6GHz channels I've just got. And now I'm not convinced it was a good idea - MT, please prove me wrong by improving TDMA on AC radios.