I just upgraded from a hAP_ac2 to a HEX S and the trouble I am having is that my internet speed is terrible, +/- 150mb on a 500mb connection. If I enable fastrack then I get full speed but my queues are disabled. I have two tenants on my property and use the queues to supply them with internet at a speed of 20/20mb each, each with a separate queue limiting the speed, and a queue that limits my speed to around 460mb, that way we don’t interfere with each other. I never used fastrack on the HAP as it was not necessary, so I am a bit confused why the hex is performing so badly without fasttrack and I am out of ideas on how to fix it.
I do understand that fastrack bypasses the simple queues just to clear that up.
My config is exactly the same on the HEX as it was on the HAP, and both running ver 7.7.
Why did you change towards a device with less processing power ? That’s not an upgrade.
Put AC2 back in.
Problem solved.
Queues are processor intensive. And the ARM processor on AC2 is bit more powerful then MMIPS on Hex S.
I used to have HEX as main router (still have it for spare), I am able to get 300Mb easily (my ISP doesn’t deliver more). Internal iperf3 testing gets me close to 1Gb (945Mbps-ish)
So apart from that it might also be a config issue.
Nevertheless, my first statement stays.
Moving from AC2 to Hex S is not an upgrade.
Could very well be.
Check processor load when running those queues. If it reaches 100%, you’re at the limit of what the device can handle.
Use Tools / profile to see what process is loading that CPU.
Yep, seems to be the case, I made an error purchasing it, seems to be a processor problem, its the only thing that makes sense considering all factors. I am so angry with myself for not thinking this through. Anyway thanks guys for the help, back to the hAP for me.
hEXes (most of them) also make pretty decent 1Gbps switches, even VLAN-enabled if one uses ROS v7.x on them. hEX S not so much though, if one wants to use SFP it hampers switch-CPU interconnect and SFP is not switched with other ports.
Hi, in my (relatively short, but intense )experience HEX S & HEX PoE are great for switching. Every installation of me has a HEX PoE as the uplink+power for my APs. Both the HEXs and HEXpoe can reach almost wirespeed on the SFP port as well if I am only doing bridging. With ROS 6.4x they can do that. On ROS6 however it took a week for me to figure out how to configure VLANs correctly without bridge vlan filtering and using the switch for vlans.
I still don´t understand the details…
The HEXs you can use HW offloaded bridge vlan filtering on ROS7 (MT7621 switch chip) , so the config is simpler. On the HEX poe with QCA8337 switch chip the config is still confusing, but it works.
If you confiure bridge vlan filtering on the wrong device, then you have bad performance.
Suggest reading the details here: https://help.mikrotik.com/docs/display/ROS/Switch+Chip+Features https://help.mikrotik.com/docs/display/ROS/Bridging+and+Switching#BridgingandSwitching-BridgeVLANFiltering
Also on this page, ignoring the following little remark made my life harder:
On QCA8337 and Atheros8327 switch chips, a default vlan-header=leave-as-is property should be used. The switch chip will determine which ports are access ports by using the default-vlan-id property. The default-vlan-id should only be used on access/hybrid ports to specify which VLAN the untagged ingress traffic is assigned to.
What I did not test yet is using the SFP port on the HEXs with ROS 7 and bridge vlan filtering. As mkx wrote: it might disable HW offloading for every port? I don´t think so, but I am not 100% sure.
It’s not what I wrote. I wasn’t specific about why using SFP as switched/bridged port would be less than ideal, but this is what I had in my mind:
SFP port, when in use, is wired directly to CPU. Leaving single 1Gbps interconnect for connection between CPU and switch chip. Traffic between ethernet ports will be switched by switch chip (just like it would be on “plain hEX” or when SFP port is not in use). But traffic between SFP port and ethernet ports will pass CPU. Possibly at wire speed, but if CPU will do anything but bridging, speed between SFP and the rest might get reduced. And CPU will sweat. This is identical case as when there’s a HW-offloaded bridge with wireless interface as member port (wired ports are HW offloaded, wireless interface is also connected directly to CPU which does the data shoveling).
Additionally: in this case it0s likely that bridge interface has to be tagged member of all VLANs passing SFP … this is a bug, discussed recently (MT staffers confirmed it without clear idea about how and when it’ll be solved).
Thanks for clarifying this, mkx! In my experience, the HExs is capable of wirespeed bridging from the SFP to other ports on the switch. On ROS6 I have tested that, of course there was some CPU load and it did not do anything else like routing or filtering.
I have no experience with the same setup on ROS7, thanks for mentioning this bug!
Sounds like the possible reason for a lot of not so fun experimentation if one misses this info…
)experience HEX S & HEX PoE are great for switching. Every installation of me has a HEX PoE as the uplink+power for my APs. Both the HEXs and HEXpoe can reach almost wirespeed on the SFP port as well if I am only doing bridging. With ROS 6.4x they can do that. On ROS6 however it took a week for me to figure out how to configure VLANs correctly without bridge vlan filtering and using the switch for vlans.