Nice summation and captures my sentiments.
I know what to expect.
But even then, other things are very confusing.default<->configured
Beacon is at 6 Mbps with default, drops to 1 Mbps with configured if allowed.
Looking in the registration-table CLI print
/interface wireless registration-table print stats
default: tx-rate-set=“CCK:1-11 OFDM:6-54 BW:1x SGI:1x HT:0-7”
configured: tx-rate-set=“CCK:1-11 OFDM:6-54 BW:1x SGI:1x HT:0-7”
configured with b-rates removed: tx-rate-set=“OFDM:6-54 BW:1x SGI:1x HT:0-7”
default but with b-rates removed in configured: tx-rate-set=“CCK:1-11 OFDM:6-54 BW:1x SGI:1x HT:0-7”
configured for 12Mbps as basic rate (and minimal supported rate.): tx-rate-set=“OFDM:12-54 BW:1x SGI:1x HT:0-7”
Beacon as expected, (and neighbors ISP AP’s as well, decoded on channel 12 !!! (=co channel interference, 20 dB more sensitive for interference than adjacent channel/noise))…
PS: If you do want Microsoft Network Monitor 3.4 you better hurry. Microsoft removed the install file from their archive. Softpedia still has it … NM34_xxxx.exe
Well , I have done my homework. Enjoyed reading beacons from some AP’s around me. And all falls into its logical place.
That old Microsoft Network Monitor cannot decode the ac beacons, but the capture file is readable and decoded by wireshark.
It’s easy to analyse the internal workings of an otherwise closed (no info in the admin interface) or foreign AP’s.
What I have learned is just explaining the wifi performance. Go back and see the importance of aggregation in a way to avoid the 99+% overhead, and then see the numbers.
I compared the MKT wAPac, hAPac2 with a similar cost old/obsolete Draytek router 2132ac.
We have A-MSDU (or MPDU) size, and A-MPDU size as parameters for aggregation capabilities. HT and VHT are different according the standards. What do the AP beacons tell us?
MKT 5 GHz ac is a superset of the 2.4 GHz n (HT) set. The HT sets are identical.
MKT HT: : A-MSDU limit = 3839 bytes , A-MPDU limit = 65535 bytes
MKT VHT: MPDU limit= 3895 bytes , A-MPDU limit = 262143 bytes
Draytek HT: A-MSDU limit = 7935 bytes, A-MPDU limit= 65535 bytes
Draytek VHT: MPDU limit = 11454 bytes, A-MPDU limit= 1048575 bytes
That 8192 number in the default setting in RouterOS for A-MSDU is somewhat misleading.
Like going to b-rates for “onlyN” mode basic rates is not intuitive. It is in the wiki, but not expected, as g/n correctly avoids b-rates.
EDIT: even the “onlyg” is as inconsistent as “onlyn”.
Aha, nice discussion…
But … don’t jump to conclusions. The slower throughput is not directly proportional to these numbers.
If you drop them in the calculators, then all is fine as long as A-MPDU is above 32768 bytes. A-MPDU is the ultimate payload, that goes in airtime competition with the overhead.
To drop the theoretical throughput on an 866 Mbps interface to 290 Mbps as absolute max, limiting A-MPDU to 16000bytes will be exactly what is needed.
So maybe the 3839 byte limit is not a problem as long as A-MPDU compensates for the smaller MPDU(A-MSDU). However the control over A-MPDU in RouterOS is minimal. Only 8 toggles on/off for each of the 8 user-priority values. And by default only set for priority “0” , luckily by default all data packets are just user-priority “0”. What on the other hand limits the WMM functionality. (By the way the WMM Contention Window and other values in the beacon are just the standard values. Again RouterOS interface gives no viiew or control over this.)
https://gjermundraaen.com/thewifiairtimecalculator/
http://www.arubanetworks.com/assets/vrd/Aruba_Wi-Fi_Frame_Time_Calculator-VHD_VRD_V2.xlsx (there is an excel error in scenario 2 not using the set interface rate)
https://howwirelessworks.com/wp-content/uploads/Aruba_VHD_VRD_Theory_Guide.pdf … a very interesting Theory guide, applied for high density but the theory is always valid, so it can be applied to the file transfer, streaming and speedtest context. And the practical examples make me wonder …" The MPDU-per-TXOP ratio is approximately 60 at 1 STA, …", or how many MSDU’s would be sent in a payload/TXOP/A-MSDU with RouterOS. 64 MSDU? An A-MSDU of 262000bytes ??
This part (the overhead mitigation) was missing in the earlier youtube presentation … it’s not used in the high density scenario, but the theory applies.
My laptop WiFi card doesn’t supports monitor mode on Windows 10, I used Winfi app to gather some data from my hAP ac2 running OpenWRT
HT:
Maximum Rx A-MPDU Length: 0x03 (65536[Bytes])
HT Max A-MSDU length: 7935 bytes
VHT:
Maximum MPDU Length: 11 454 (0x02)
Max A-MPDU Length Exponent: 1 048 575 (0x07)
MU Beamformer Capable: Supported
According to the dev who helped to port OpenWRT (Robimarko) to the hAP ac2 and other IPQ4018 Mikrotik products they’re using QCA drivers but their AP implementation it’s not standard compliant and lacks the wave 2 feature set.
https://forum.openwrt.org/t/can-open-source-drivers-ever-be-as-good-as-proprietary-ones/72832/40
I think they haven’t migrated to something like hostapd to avoid deprecating all their propietary stuff like Capsman, hotspot, NV2, nstreme and so on (most of those can be rewritten to support the new implementation).
PD: I know I can just enjoy my OpenWRT powered ac2 and leave this forum but advanced routing features (like VLANs) are more polished on ROS.
One posting later it says:
It´s hard to believe, but MikroTik really writes their own wireless driver. MikroTik regularly confirms this in it´s forum, e.g.:
http://forum.mikrotik.com/t/802-11ac-wave2-support/127501/1
“You are right, that MikroTik made wireless driver doesn’t have Wave2 support, so new chipset benefits are not there. We are working on a new driver.”They use their own wireless driver package, which is independent from the linux kernel:
http://forum.mikrotik.com/t/ros-7-wireless/134524/1
“Since at the moment v6 and v7 uses identical driver and software for wireless, your observation is most likely a coincidence. The performance should be the same, signals also.”http://forum.mikrotik.com/t/802-11ac-wave2-support/127501/25 > 2
“Most of the features are implemented, but MU-MIMO is WIP”
Spiderman pointing meme.jpg
We really need to get hAP ac2 into official OpenWrt branch…
I don’t know embedded device programming 
It does exist. (not tested) 
https://openwrt.org/toh/mikrotik/hap_ac2
@hiedarren
…
Lets think about that statement.
If 867 is the advertised two way speed, also called the ‘marketing speed’
The best one way speeds physically possible are 433. AKA 1/2
Factor in some losses, and the 1/3 rule is realistic for a plain wifi 5 device which yields 289.
Now with new features and capabilities added to wifi 5 and standard on wifi 6 etc, the losses are minimized but only to a certain extent on other devices using standard chips and programming.
Mt with the capac and proprietary programming has fallen short in stability and speeds and perhaps some folks can see more than 300Mpbs but its probably rare.
But to state someone is getting 2/3 of the advertised speeds LOL. I just need you to explain the physics on that one or retract your statement.
By the way for roughly the same price point I changed from capacs to tplinkeap245v3 wifi 5 access point that can also read vlans.
It has an additional chain and thus has 1300 advertised speeds and 1/3 = 433 and I am able to achieve that plus some due to Mu-Mimo functionality added etc…
But I can say I have never achieved anything over 650Mpbs (1/2), let alone 866Mbps.
Within LOS I certainly can achieve 600 down 500 up.
The math is not difficult, it is already done, you just have to fill in the numbers. THE difference between MT and others is the MPDU size (and corresponding A-MPDU).
WinBox suggests 8192 is used , we know from the AP’s beacon that it announces 3895 (the lowest standard value, while others claim 11454 bytes (the highest)
CAPsMAN claims 2048 (!)
Filled in the calculator found here: https://gjermundraaen.com/thewifiairtimecalculator/
More specific URL on that page for the spreadsheet: https://gjermundsblog.files.wordpress.com/2019/10/the-wifi-airtime-calculator-version-1.xlsx
And assuming 8 MPDU buffers in one A-MPDU , it gives recognisable numbers: theoretic max for MT standalone and others of 376Mbps and 600Mbps
This 8 MPDU is just an assumption, calculated with this larger packet and the mandatory A-MPDU “block ack” for the 8 MPDU in one simple ACK packet is included.
(There is no 50% send/receive division. This is like a roundabout, every lane tries to get on it and has equal chances (unless WMM is used, then there are priority drivers)
If one wants to extend this to triple stream … easy just replace 2 with 3 and you get speeds like 434Mbps for MT and 776Mbps for others.
And now we optimize when the conditions are good , rising the basic rate from 6Mbps to 24Mbps … becomes 544Mbps and 844Mbps for triple stream
For dual stream the data rate changes from 376Mbps(MT) and 600Mbps(others), to 424Mbps and 640 Mbps, when basic rates is 24Mbps.
And down to CAPsMAN, or anyone who reads the forum and sets it to 2048, … 2048 byte MPDU, 6 Mbps basic rate, dual stream … 247 Mbps
Setting A-MSDU=MPDU to 2048 is a good thing to do, for some conditions, not if you want max speed.
That’s without any disturbance (but RTS/CTS included, as the wide channel of 802.11ac requires AFAIK.) There is some air-time loss for the beacons, with beacons at 6Mbps, count on 0.5% per AP- SSID transmitter, at 1Mbps it is 3% !
600/866= 69% (others and wifiwave2)
367/866= 42% (MT)
247/866= 29% (MPDU=2048, A-MPDU=*8)
PS: If you do want Microsoft Network Monitor 3.4 you better hurry. Microsoft removed the install file from their archive. Softpedia still has it … NM34_xxxx.exe
Microsoft Network Monitor neither NPcap drivers work on my new laptops (WIN10, 64bit). So capturing wifi beacons and management packets is gone.
The Free “WinFi” wifi monitor stopped working everywhere, also the old installs.
But no worry. Any Mikrotik AP can do it. Using the “Wireless Sniffer” on a WLAN interface catches those. (This is NOT the Sniffer in Tools!)
Saved in a file, and downloaded for Wireshark, gives again the decoding of the “beacons”.
EDIT: Well I have another way to collect all Beacons in the area just with the laptops. With the free InSSIDer software , the “File->Export Summary…” creates a file with all the beacons received in all bands and channels, one beacon for every SSID+AP combination. The file is decodable by Wireshark, and it does not contain other data packets.
So bpwl, from a practical standpoint are you saying the MPDU is only configurable via capsman?
Not really. (I’m not a CAPsMAN user, maybe I should set one up on one device just to see what it does on performance. As people in the forum say the WLAN settings have no importance if CAPsMAN is used, looking at the Beacon would be what I would check.) A-MSDU and A-MPDU parameters are not in the wiki for CAPsMAN. I read in this forum (and some other blogs) that CAPsMAN sets the AMSDU size to 2048 by default. (Some explanation is that it then fits into the wifi MTU. But the 802.11 standards and beacon fields don’t have such a value for MPDU (=A-MSDU).)
Setting A-MPDU on or off is in the WLAN interface. By default only for priority 0 !
0,3 (BE: best effort)
1,2 (BK: background)
4,5 (VI: video)
6,7 (VO: voice)
Setting the A-MSDU=MPDU size and threshold is also there.
The priority itself is set in mangle rules, as it is not received or transmitted, It can be calculated from the DSCP bits. (DSCP travels with the packet.)
So what are you recommending for the capac
for optimal numbers to put in those two top settings (AMSDU entries),
and what you recommend should be checked off in the below settings (AMPDU settings) .
I’ll take the screenshot in post by @bpwl as a recommendation 
Question for me still is how to implement the priority mangle rule in an efficient way, when we use a simple (C)AP connection, with bridged ethernet and WLAN interfaces.
Packets are processed by CPU because of WLAN interface not on switch chip, they do not pass the firewall by default, and if we set “use IP firewall” on the bridge, can we still Fastpath or Fasttrack, or is there no need for this? What chain to use? “Prerouting” or “Postrouting”? Connection-mark for faster selection?
Is setting DSCP of any use here?