I've really been wanting to answer the question how fast is NV2 compared to 802.11 advertised speeds? I've built a lab and tested this out with 1 AP and 2 clients. Client1 and the AP are on the 192.168.1.0/30 network, and Client2 and the AP are on the 192.168.2.0/30 network. I then setup a udp traffic generator to go from Client1 to Client2 across the wireless network that the AP provides. I maintained CCQ percentages above 95% through my whole tests. Here are the results below with all devices running RouterOS 6.45.5 with upgraded firmware. All tests were conducted with Groove52HPnD on the 20MHz 5ghz channel (1:1x1 data stream using 802.11n hardware). As new RouterOS versions come out, I'll add new charts. I also used a pre-shared key for security to demonstrate the expected performance hit of encrypting your wireless traffic (you should turn this on). I also enabled AP and clients noise immunity, and I used dynamic downlink 50%. Results below, shown in Mbps aggregate.

Interesting! Thank you for putting in the time and effort to analyze and share it with us!

The wireless protocols ( 802.11 & nstream & nv2 ) each have their advantages.

802.11 ;PROs , compatibility with just about everything
802.11 ; PROs , great for point-to-point Mikrotik WDS links and probable the fastest protocol for point-to-point ( one AP and one client )
802.11 ; CONs , horrible throughput in noisy environments. Example a mountian top AP with 30 far-distant clients where there is rouge noise every where
802.11 ; PRO and CON , prior to sending the transmitter needs to first listen and make sure the channel is clear ( if the channel is not clear then it waits ). This waiting can slow down all thorughput when there is an AP with many remote distant clients.
802.11 ; CONs , subject to over the air collisions which thus creates retries

nstream ; a polling protocol - The AP will tell each client when it can transmit. Solves some of the problems with 802.11

nv2 ; PROs , best for APs with many clients in noisy environments
nv2 ; PROs , no collisions between AP to clients and no collisions between any two clients transmitting at the same time
nv2 ; CONs , nv2 is a Mikrotik hybrid-custom TDMA protocol and is not compatible with non-Mikrotik devices
nv2 ; PROs , nv2 ( TDMA ) adjustable/tuneable time-slots can be tuned from a 50/50 ratio ( 50 percent of the time in AP transmit mode and 50 percent of the time in AP receive mode ). I normally use a 75.25 nv2 ( TDMA ) ratio where the AP is configured for 75 percent of the time to be in transmit mode and only use 25 percent of the time to receive. Almost all Internet clients receive ( download ) far more data than they send ( upload ). So for an AP with many nv2 clients , this works out well to allow more data to cutomers.

I have thousands of Mikrotiks in my networks and all of them are nv2 --- with the exception that I use 802.11 for point-to-point WDS links.

North Idaho Tom Jones

I've since done some preliminary testing on ROS 7.1 and what I've found so far is that the performance on NV2 is identical. I don't see any improvement or loss in speeds so far after testing NV2 auto.

Re 7.1

Two days ago, I upgraded a remote site ( NetPower 16P -and- 5 nv2 APs -and- two 802.11 WDS links to 7.1 ). ( I did not upgrade any wireless customers to 7.1 )
Things went horrible...
- I could not achieve a reliable Winbox connection to anything ( my equipment or any of my remote wireless customer Mikrotik's ).
- Connections were dropping.
- Sometimes , I could not perform a MAC-Telnet from a nv2 AP to some clients.
- Bandwidth dropped and complaints started coming in.

I downgraded the entire remote network back to ROS version 6.49.2 and presto ... everything started working good.

North Idaho Tom Jones

Interesting info, thanks for sharing.

My experience with 5xSXTSA5 ac and 15 receiving SXTsq 5 ac in a circle of 1 km .... 40 MHz/2S links are at 400Mbps interface rate , 260 Mbps effective rate, using "nv2", 125 Mbps bidirectional.
Clients are connected to 30 AP (hAP ac2, cap ac, wAP ac) connected to the SXTsq 5 ac. Clients get up to 160Mbps to internet (internet uplink speed limiting)
There is one SXTsq 5 ac - SXTsq 5 ac link, as only PtP was needed. (cost saving, interference reduction)

Setup is PtMP from "SXTsa5 ac" to 3 "SXTsq 5 ac" each, where SXTsq will follow the SXTSA5 made selection for 802.11ac, nstream, nv2
After tests nv2 gave the best performance

Following considerations have been made for the solution taken:
- 802.11ac is rather new. Not clear if WDS will handle this well. For 802.11n the other brands documents state clearly that WDS is not doing aggregation and therefore has reduced performance. With 802.11ac and higher interface rates, that aggregation becomes very important for the performance.
- WDS is avoided, it is not needed for Mikrotik PtP and PtMP. The "AP-bridge"+"Station-bridge" combination supports 4-address transfers, and uses all 802.11ac features and aggregation.

ROS version: 6.45.6. ROS 6.47.10 considered as AP upgrade.

I've been trying to put together a better test mentally for this. So far with just using a single AP and two clients in different subnets to test this, first with bandwidth test and also with packet generators. Unfortunately maybe what I'm seeing is that ROS 7.1 is stable for 1:1x1 on 20mhz 802.11n type protocols and speeds, but I don't have other hardware to test with. I'm using two grooves as clients and testing them across the AP wireless interface so that I am not stressing the CPU for the AP. I would like to keep using the mipsbe processor for testing since there are far more units of those deployed in WISPs. Maybe I need to start testing with desktops and iPerf? I'll for sure try that. Do I really need to expand channel widths to beyond 20mhz? I liked the idea of using 20mhz and demonstrating that using 40mhz is just 2x the speed on a 20mhz channel, and and 80mhz is just 4x the speed. Adding extra chains and streams would be additional multipliers to speeds, but clearly something in ROS 7.1 isn't allowing your APs to perform the way you like, so I need to find the right scenario to build and test with to really draw out the aspects and demonstrate what operators should expect with each new ROS release.