we got 6 RB962UiGS-5HacT2HnT but the performance in our network is horrible. So we tried to play with it a little bit and compared it to Ruckus which has steady results around 150 Mbit/sec. We tried the default settings with 6.34.3 and we got following results on iperf:
0.00-10.00 sec 48.0 MBytes 40.3 Mbits/sec sender
which is not really good. So we played with it a lot ..
today, we tried 6.35 RC41 with wireless-rep and latest firmware
The results were following:
0.00-10.00 sec 3.50 MBytes 2.94 Mbits/sec sender
Which is really horrible.
But then, desperatelly clicking around we disabled under IP settings to uncheck Allow Fast Path and uncheck Allow Fast Path under Bridge Settings… then we got this result:
0.00-10.00 sec 119 MBytes 99.6 Mbits/sec sender
Which is useful, on receiving side we got around 200Mbit/sec even after reboot
So I want to ask what can be wrong? Why is fast path doing this? We tried to uncheck this on 6.34.3, but it had effect until the device was rebooted and then no matter what you check its doing crappy.
The config that was loaded on that worst result is following:
/interface ethernet
set [ find default-name=ether2 ] name=ether2-master
set [ find default-name=ether3 ] master-port=ether2-master
set [ find default-name=ether4 ] master-port=ether2-master
set [ find default-name=ether5 ] master-port=ether2-master
/interface bridge
add admin-mac=E4:8D:8C:49:1E:94 auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-Ce \
distance=indoors frequency=auto mode=ap-bridge ssid=MikroTik-491E9A \
wireless-protocol=802.11
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40mhz-Ce \
disabled=no distance=indoors frequency=auto mode=ap-bridge ssid=\
MikroTik-491E99 wireless-protocol=802.11
/ip neighbor discovery
set ether1 discover=no
set bridge comment=defconf
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" mode=\
dynamic-keys wpa2-pre-shared-key=PASS
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2-master
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
192.168.88.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=\
ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 name=router
/ip firewall filter
add chain=input comment="defconf: accept ICMP" protocol=icmp
add chain=input comment="defconf: accept established,related" \
connection-state=established,related
add action=drop chain=input comment="defconf: drop all from WAN" \
in-interface=ether1
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add chain=forward comment="defconf: accept established,related" \
connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
out-interface=ether1
/system leds
set 1 interface=wlan2
/system routerboard settings
set cpu-frequency=720MHz protected-routerboot=disabled
/tool mac-server
set [ find default=yes ] disabled=yes
add interface=bridge
/tool mac-server mac-winbox
set [ find default=yes ] disabled=yes
add interface=bridge
I know my firend is having the same AP, with 6.34.2 with much better performance in almost default config. So I think this series might be faulty? Should we return all of them? The iperf is showing over 800Mbit/s when we try this over one of the ethernet ports on HAP AC (EDIT: just one way as we found out later on). LAN is connected to ether1.
This definitely is not ok and we’d like help you to resolve this issue. Please write to support@mikrotik.com and add this forum link as reference and attach supout file of hAP ac board.
So after some more testing we decided to get SFP S-RJ01 - and guess what - everything is running very smooth and fast - over 500Mbit/s with wireless-rep symetric
So we tested some more and we suspect that the switch might be the source of problems, because when we tested on wired connection with SFP for WAN and ETHER1 for LAN we get following: When we run iperf with -R option, we get 838 Mbits/sec but, without -R option we get only 68.5 Mbits/sec!
When we switch from SFP to ETHER1 for WAN and ETHER2 for LAN we get 34.8 Mbits/sec upload and 18.5 Mbits/sec download with iperf.
Just to be sure, we tried older RB951G - we wiped all settings, then we just briged ether1 and ether2 and ran iperf - it was around 900Mbit/s both ways.
So … changing wireless package to wireless-rep fixes part of the problem, but it seems the switch is source of the problem also - is anybody else experiencing this? I tested two HAP AC with the same result. Both have qca-8337 switch installed, RB951G has Atheros 8327
Unfortunately we need PoE to run the APs, so its unusable like this for us. So I guess we should return all of them…
So we got one more HAP AC and it is working correctly. So its definitely a faulty series.
The one that is OK has SN: 6737055FAF54
Two APs tested today, that have this poor result have SN:
6737051BD37F
673705E06641
I will test the rest tomorrow.
Too bad, that support is not responding at all - so I guess there is no other choice than to return all of them. Really disappointing - I would recommend to all customers who want to buy HAP AC to wait some time until this is somehow resolved or to choose different product.
Hi, so we have found the source of the problem - its temperature. We cooled down the unit to 15°C and started testing.
The results were following with iperf and System/Health temp:
15 °C
0.00-10.00 sec 924 MBytes 776 Mbits/sec sender
0.00-10.00 sec 848 MBytes 711 Mbits/sec receiver
It is reproducible on 2 units. For the rest it was enough to use wireless-rep package with 6.35RC ROS - problem was occurring with some Intel wireless cards (eg. Intel Dual Band Wireless-AC 8260 in Lenovo Yoga 900), but using wireless-rep is fixing that.
So after we get some kind of replacement for those heat affected units we will send those back to you.
I have been experiencing the same issue on the excellent hAP ac and have found:
the low bandwith (17-57Mb/s) varies with temperature
it occurs with certain ethernet phys and not others
when it occurs, I see receive issues, suggesting the root cause is the transmit from the QCA8337 switch chip
the temperature of the heatsinks on the QCA8337 are fine, suggesting there is sufficient PCB thermal coupling (ie there isn’t an PCB error with thermal relief for soldering)
This all points to an issue with QCA8337 phy programming, so is highly likely fixable in software; this makes sense since it is newly introduced and has new mac and phy power-saving features which may cause compatibility issues with some equipment.
I can’t reproduce the issue against Intel ethernet macs and phys, but I can with an Asix AX88179 USB3 to ethernet adapter, which shows a low rate of receive errors. The QCA8337 side shows no errors in the stats.
@Mikrotik, let me know if you need more data/info/testing. I can hook up my 200MHz scope if needed.
I also have a weird problem with ethernet performance of HAP AC (6.35). Here is the summary:
The good:
The Speedtest.net over both wireless (ac) and ethernet gives the same result on the same server;
Ethernet performance in local network is also good. Copied a file from one PC to another, almost got a gigabit.
The bad:
The actual internet speed on ethernet is awful. On wireless it’s ok (so it’s not an ISP issue). I get normal speeds when downloading a file over wireless and I get very poor performance on wired. So speedtest.net is ok, every other thing I try is not ok. For example on whatbox.ca/speedtest over wireless I get > 5 MiB/s and over wired I get < 300 KiB/s!
UPDATE. Seems that speed drop over ethernet appears only when downloading files from relatively distant servers. Again, the wireless is good.
UPDATE2. I bought the HAP AC as a replacement to RB951G-2HnD and the latter works as expected.
I think I had a similar issue with 2.4 band. It seems there is a bug in current software and the workaround for me was setting the 2.4 wireless channel to auto. Any other value was drastically dropping the 2.4 wireless speeds. If this doesn’t work, try to reset the configuration.
UPDATE3. I’ve done some additional testing, plugged off the router from power source, after an hour plugged in. Guess what? Speeds were ok, this means that the other guys here are right: temperature is what causes the speed drop. After some playing the speeds went down again. Quick re-plugging didn’t help. However when touching the device in normal use (when speeds are low) I don’t feel like it’s too hot.
UPDATE4. Indeed, cooling down the router in a refrigerator a bit fixes all the symptoms.
UPDATE5.
The customer support has suggested a test: to put the ethernet interfaces into a bridge (after setting master-port=none). I think, the intention of this was to check whether the problem comes from the switch chip. I was pretty sure it was… Because the wireless works, and wireless is in a bridge mode. However, the symptoms were the same even after putting all the ports into a bridge.
To sum up:
Wireless seems to work normal in every condition;
Wired works normal when in a local network (gigabit download/ upload); when the download server is near (e.g. in same country); when testing through Speedtest.net (regardless of the server location - this is the strangest part)…;
Wired works terrible when the download server is relatively far from you. However, this also doesn’t happen when the router is cool. In normal working temperatures (system-health) of 55C I get less than 2Mbps (yes, megabits). It seems that the speed drop (e.g. 2Mbps when the temperature is 55C) occurs on every single connection: when using torrents I get the same speed drop on each connection; the total download speed may still be high;
The good-old 951G seems to work ok on the same ISP;
Bridging the ethernet ports doesn’t improve anything: this may suggest that the problem is not in the switch chip itself;
Support says that they never had a faulty HAP AC unit of this kind: this means either 1. there is only a batch of faulty HAP AC’s; 2. all the HAP AC’s are the same: there are conditions, which were not been covered by Mikrotik’s testing, at which the problems appear.
In my opinion there is no faulty batch of these units. I think the issue we experience appears as a coincidence of a software (maybe driver) bug in RouterOS somehow related to temperature (kind of cpu throttling) + some ISP’s non-standard infrastructure configuration. This can explain why:
Only fraction of users experience this kind of problems on HAP AC: those may have ISP’s with different infrastructure;
Mikrotik testing didn’t detect anything: in local networks + in local area (like in same region) these units work fine. Also Speedtest.netglobally works fine. Also maybe (?) their ISP (ISPs) have “normal” infrastructure.
The older boards work fine for us: those are cooler. Those don’t have 2 different wireless chips, POE output…
What I’m going to do is checking my old 951G router speed correlation with the temperature. Maybe I just wasn’t noticing that (because it was cooler, thus faster). Unfortunately this is not going to be in near days: I’ve already spent to much time with these things…
Doesn’t anybody from Mikrotik want to respond here?
Thanks @TaurusThree for your test.
Can anybody else own a HAP AC confirm this issue?
How long would it take Mikrotik guys to confirm this and release a firmware/software fix? I’m holding to buy some HAP AC while this faulty is not acceptable for me.