Just some comments on the tuned config file.
There is quite some tuning done. Tuning is always a balance between gain and loss. The loss is certain, if the gain is not higher than the loss the tweak should not be done.
Based on my understanding and experience only. Still improving my tuning skills.
/interface ethernet
set [ find default-name=ether1 ] name=WAN speed=100Mbps
set [ find default-name=ether2 ] speed=100Mbps
set [ find default-name=ether3 ] speed=100Mbps
set [ find default-name=ether4 ] speed=100Mbps
set [ find default-name=ether5 ] speed=100Mbps
You don't trust the auto negotiation? 100 Mbps is indeed potentially a trap with the half/full duplex mismatch.
/interface wireless
set [ find default-name=wlan2 ] adaptive-noise-immunity=ap-and-client-mode \
band=5ghz-onlyac channel-width=20/40/80mhz-XXXX country=japan disabled=no \
disconnect-timeout=15s distance=indoors frequency=5260 frequency-mode=\
regulatory-domain hw-protection-mode=rts-cts hw-retries=10 mode=ap-bridge \
multicast-helper=disabled name=LAN-wfi5ghz on-fail-retry-time=1s \
radio-name=MikroTik5G ssid=MikroTik5G tx-power=25 tx-power-mode=\
all-rates-fixed wireless-protocol=802.11 wmm-support=enabled wps-mode=\
disabled
channel width=20/40/80mhz-XXXX frequency=5260 -> you need 4 consecutive 20 MHz channels , and with XXXX you don't know which ones will be choosen.
(52-56-60-64) any other list where channel 52 is in. ANY traffic in one of the choosen channels will make the transmission wait.
A site survey (scan, freq usage, snooper) will learn if there is enough silence on those channels. If NOT. Then 40 MHz could be a better choice.
(The 50% loss is certain, the gain depends)
With Ceee, eCee, eeCe or eeeC there is some more control on the channels used.
hw-retries=10 -> trying somewhat longer than normal. The MCS rate adoption to a lower MCS may be delayed. On the other hand it may help to stay on the high MCS rate.
In a troubled environment hw-retries=3 could help the interface rate selector to adapt faster. Only experimenting will tell.
on-fail-retry-time=1s -> this is longer than normal. Wait a full second before retying a lost connection? Default is 0.1s , or 100 ms
TX power is probably limited by regulatory domain, to 23 dBM.
From CLI: interface wireless info country-info
country: japan
ranges: ....
5170-5250/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(23dBm)/passive
5250-5330/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(23dBm)/dfs,passive
5490-5710/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(23dBm)/dfs,passive
rts-cts : yes if there is a "hidden node" case. (e.g. TV does not reach till PC).
multicast-helper=disabled -> all multicasts are sent as multicast at the broadcast basic-rate. For b = 1Mbps, g= 6 Mbps, for n and ac still studying : is it the lowest basic rate (MCS0= 6 Mbps) or the highest basic rate lower than the current lowest interface rate?)
wmm-support=enabled (still studying what the impact is) but how can it work without the QoS priority mangle rules. Everything is priority 0! No differentiation or special handling.
idem for possible "a-mpdu" settings .Everything is priroity 0 without QoS mangle rules. It is by default enabled for priority 0. (And that's important!
viewtopic.php?f=7&t=161295) As you can read there and elsewhere, lowering the a-msdu (8192->2048) is also a tuning act in a setup with many retransmits, if a-mpdu is there to compensate the huge loss that lowering the a-msdu introduces. The hw-retries=10 setting indicates you have seen retransmits.
