What could be the reason why Hex would chop my Internet speed by half? speedtest and fast.com shows the same results.
I’ve reset my Hex to factory defaults, with default config just to isolate things, but it still cuts my connection in half. My negotiated connection is 1G so cable between modem and Hex is fine. When I connect directly to the modem I’m getting my full speed.
Hi,
What is the contracted speed with your ISP?
Export settings and share:
/export hide-sensitive
Regards,
Direct to modem speed is 800mbps.
After connecting to mikortik, it becomes 400mbps.
All cables used are cat6 and nego to 1g.
I’ve reset to factory default config.
Hi,
Did you try fasttrack?
https://help.mikrotik.com/docs/pages/viewpage.action?pageId=328486#PacketFlowinRouterOS-Fasttrack
Regards,
Factory default already has fastrrack enabled
And see what really applies?
With your ISP’s modem do you really get the speed?
yep, direct connection to modem shows correct bandwidth
What RouterOS and firmware version is the hEX running?
hex gr3 ros 7.8
Check test results on product page. Many of us find number listed under “Routing → 25 ip filter rules ->512 bytes” to reflect real-life performance pretty well (yes, there are particular use cases where cevices perform much better and there are use cases where devices perform even worse). Mind that for older devices (which were introduced in v6 era) test results are correct when running ROS v6 … ROS v7, due to architectural changes in used linux kernel, has quite a bit worse routing speed.
It is always possible to downgrade ROS version, factory installed version is the lowest possible. So if your hEX came with v6 from factory, you can try to downgrade to 6.49.7 and see how it performs. Unless you absolutely need some of new features in v7, in which case you’ll have to live with lower performance.
My gr3 came with a more recent ROS v6. I upgraded it to ROS v7 because I was under the impression that it’s faster given the hw offloading support which isn’t present in ROS v6 for this particular chip
This particular chip has quite a few features which unfortunately are not used in ROS. Feature which got supported in v7 but isn’t in any of v6 is HW accelerated switching with VLANs used. Which has nothing to do with routing (even if VLANs are used this way or another). And depending on your particular use case it might not be used even for intra-LAN traffic (if you use device as router/switch combo).
My original (and intended config) uses VLANs for separation and control, which may potentially include queue as well (PCQ at the top of my head).
Queuing is currently incompatible with fasttrack (which in turn is prerequisite for L3HW offliading if I’m not much mistaken).
If you use vlan-filtering=yes on your bridge, then indeed v7 should make this part better on hEX. But the part about routing performance I mentioned is still true.
So, if I were to weigh what I need, I’d say preserving bandwidth would be first, VLAN second and queueing last (since I can’t do queueing with fasttrack enabled). Is fasttrack a mandarory setting to ‘preserve bandwidth’?
With that in mind, I may need to downgrade to the latest ROS v6 then.
If you’re saying that having best routing performance is the most important thing your hEX, then yes, downgrading to v6 would be the best way to go.
Fasttrack is instrumental in getting decent performance on devices with slow CPUs (which is almost all Mikrotiks apart from top CCR models).
I’ll be downgrading later and get back on results. Hopefully that fixes the missing badwidth…
Looks like given the fasttrack requirement, queue is a no go for me then.
As far as VLAN is concerned, my only use of it is separation and blocking of 3 untrusted ones from LAN access.
If you can isolate those untrusted devices to single router port, then it would be beneficial to use that port as stand-alone port for separate subnet … that way you wouldn’t need VLANs and hence there would be no performance hit when using ROS v6.
If you have to keep using VLANs, then … as soon as you enable vlan-filtering=yes on bridge, L2 (switching) HW offload is lost and then it’s up to CPU-bound bridging. Mind that bridging is much easier on CPU than routing, but it’s still a hog. While it is possible to get at wire-speed throughput between a pair of bridge ports, that’s not possible to reach simultaneously on all ports (due to switch-CPU interconnect bottleneck) and CPU will be heavily loaded (thus eating into routing throughput).
Unfortunately, no 
Though it’s technically possible to lose the VLANs, I might as well just plug in directly to the modem 
What could be intresting to know is which is more of a hog vlan in v6 vs routing in v7.