Today I got my package with the brand new Hex S 2025 (E60iUGS) edition. Previously I had RB750Gr3.
Reason for upgrade is that I wanted more performant gear for firewall rules, also RB750Gr3 had some problems with full speed on PPPoE 1Gbit link.
I unplugged old device, plugged in new one, added VLAN and PPPoE and I’m able to access the internet.
My max speed is now capped at 130-160mbps… Old one was ~930mbps
Default configuration except for 2 interfaces - VLAN and PPPoE client.
Old router was just fine with that.
I have access point on ether2.
Now there are few strange things going on.
#1 - if I open terminal and do /interface ethernet monitor ether1(same output ether2) I get this:
#2. If I do speedtest from PC → AP → ether2 → ether1 → PPPoE - I have ~130-160 mbps, much below the expectation. #3. If I do speedtest from PC → ether 3 → ether1 → pppoe - 800-900 mbps (in this case I skip the AP) #4. If I do speedtest from PC → AP → ether2 → ether3 I have full 1gbps speed. (still using AP but only testing internal network)
I’m sorry to be the bearer of not-so-good news, but others are complaining of similar symptoms. What seems to resolve it is to use ether2 instead of ether1 for the WAN port. (Of course following removal from the bridge.)
Can you test this and confirm?
EDIT: I see that you are using ether2. Any of ether2-5 will do for this test. It’s only ether1 and the SFP that’s internally connected differently.
In theory it should be able to handle the PPPoE without breaking a sweat.
And I don’t seem to be affected by the bug you mentioned. I identified that my Access Point on ether2 is slowing the connection to that miserable speed (does not happen when connected to old Mikrotik). Anyway, even without AP I can’t get over 900mbps, let alone adding more advanced firewall rules to that.
I’m going to refund this gear, it is not worth it.
Well, it’s obviously good news that the problem is not as widespread as some thought.
900 Mbps btw is approximately what you would expect on a 1Gbps connection. This is usually a result of various overheads (inter-packet spacing, additional headers, etc.) ISPs around here specify their 1Gbps connection in the fine print as 850+ Mbps technically.
Does the CPU max out during the test? Does one core max out? (Just out of curiosity.) I think it’s a bit on the limit, but I would expect it to handle 1Gbps PPPoE fine, though definitely not without breaking a sweat.
EDIT: I get about 940 Mbps on a nominally 1Gbps connection, but its DOCSIS, so the only place where the connection is physically 1 GbE is between the modem and my router.
On Hex S, /tool profile shows 80-85% CPU.
On RB750Gr3 it is 30%, (but UI System → Resources, core load goes to 80% too).
About the speed, device provided by the ISP is able to get to 960-980mbps (but the software is bs).
Hex S with 800mbps is no-go, I will stay with RB750Gr3.
By the way, I was sold by the benchmarks, but it becomes clear that RB750Gr3 is waaaay over E60iUGS. The specs/benchmarks are completely off then. Is that correct?
Okay, thanks. If you happen to have the time, could you test with ether 2-5 as a WAN. Then it’s the same switch chip, network interface, etc. with a more powerful CPU. I would be really surprised if it underperformed the hex r3 in that configuration.
Anyway, if you could create support ticket and supout, that could help get the problem fixed.
Unfortunately yours is not the only story of disappointment with the Refresh series. I am quite hopeful that this will be fixed in software (other devices that use the same series of Airoha SoCs have also had some teething problems.
For now, I am in full agreement that you should return it. If it doesn’t meet your current needs and expectations, and you can do so easily, the situation is clear enough.
If you are getting 940 Mbps, you are good to go.
The connection is 1gig and with normal losses around 940/950 is very reasonable.
I have a highpowered router and I dont get more than 940 on my 1gig connection.
UP your ISP connection if you want more speed.
If you wanted a router with up to 1 gig throughput not sure why you looked at hex S at all… ( its rated to give out 400-700 at most )
Your best bet (cheaper route is hapax3 and after that RB5009.
Oh my… yeah, running PPPoE on ether2 fixed the problem. Now I get 910-930 mbps where it used to be 130mbps. CPU load is also spread more evenly on both CPUs (50-60%).
I guess there is a bug.
So you see, I compared few values, opened benchmarks etc. my fault.
I do have 3x hap ax2 as access points with fast roaming, my goal was to upgrade my guear and to have advanced rules for routing guest network (smart home) with firewall rules.
I only require wired network to be as performant as possible but I failed miserably (by picking Hex S).
No custom firewall rules, only the default ones.
I am surprised - but in a positive way. Moving PPPoE from ether1 to ether2 on Hex S helped a lot, it is way closer to what I can achieve with RB750Gr3.
We compare 130mbps to 930mbps (almost max), that’s a huge improvement. But it also mean that ether1 is bugged.
Yeah, then you’re having the exact problem I was talking about.
I have an educated guess related to its causes, and I have a guess that it will eventually be fixed in the driver. I don’t for a moment claim to know when or if such a fix will be forthcoming.
My point regarding whether to keep the device sadly stands: if you can live with only having 4 - let’s say - “full capability” ethernet ports available, then sure, with this limitation it performs according to what would be expected based on published data. If you don’t see this as viable, I can only suggest returning it. That’s my usual suggestion to any networking equipment from any vendor - if in its current/as-shipped form doesn’t meet your needs, just treat it like it never will. (And then reconsider if something changes.)
Again, sorry for being tiresome, but if you have multiple ax2’s, why not just use those for this task as well? They are actually more powerful than either the r3 or the Refresh, and would easily handle this job.
I see. It also tells me why the connection over AP from ether2 to ether3 was much faster than to ether1.
So this router is very SFP oriented. I guess the preferred setup is to have internet access over SFP, ether1 as PoE In, then ether2-5 as “main” router inputs.
No, you’re very helpful. In my head I had 1 main router to configure all network (in this case Hex S or RB750) and 3x AX2 as access points to it.
But you are actually much right. I can make 1 AX as main router, and 2 as secondary access points, fast roaming is must have. Do you think that would make a valid configuration?
The “how many firewall rules” thing is a bit of a myth. For normal firewall rules (by this I mean matching addresses, interfaces, connection state, etc. NOT L3 filters, etc.) it doesn’t really matter if it’s 1 or 50. (Okay, for hundreds or thousands it might matter.) Yes, I’ve actually measured it.
With most of the data passing in fasttrack, as the OP says his router is configured (indeed the results would be wholly suspect otherwise), the number of firewall rules wouldn’t matter, as they are bypassed.
EDIT: The things in firewalling that burn CPU cycles are: the conntrack lookup, updating the conntrack entry (have you ever looked at how many counters are maintained and updated for each packet?), the creation of the netfiler metadata for firewalling, etc. The number of rules then executed on them has a barely measurable influence. (Again, normal rules, and not thousands of them.)
EDIT2: Anyone can test this themselves quite easily, just add 50 rules that won’t match any packets at the beginning of your forward chain, before the established/related rule.
In fact, I now understand why benchmarks showed such speeds.
I don’t think that ether1 interface can ever be fixed it looks like a placeholder for PoE.
Ether2-5 look like a primary interfaces in this router.
Thank you guys for all the insights, you are very helpful.
I’m going to return Hex S, but at least there is lesson learned.
He doesn’t. Furthermore, he is using fasttrack. The number of rules doesn’t matter that much, since they will be fasttracked almost all of the time.
People saying the 750gR3 (I know, I know, another device) can’t do 1Gbps is always thinking about it without fasttrack. There is no reason to run those small units without it, and even less reason to set a heavy firewall on them. These small units (the hEX 2025 has some serious bugs that I hope will be ironed out) shine when used for what they were made: a small SOHO router, with a very streamlined firewall and a simple firewall.
Used this way, one could - easily - route 1Gbps on an RB750Gr3. Vpn would be slow, complex firewall rules would bog it down, and one would HAVE to use fasttrack. But doing this? A truly gem - cheap, sipping energy, small and functional. The 2025 refresh SHOULD do the same, since it has a (much) better CPU. But we have those annoying bugs to be ironed out first.
The “look at the block diagram” people are a bit misguided. Yes, different interfaces will always behave a but differently (they often result in different CPU loads for example for a given traffic). But the differences shouldn’t be this dramatic. For example, the L009 has its SFP attached similarly and with no loss of throughput (of course it uses different chips from different manufacturers.) There is something wrong here, but again, given that these are Mikrotik’s first devices on the given platform, and that other manufacturers has similar problems, I’m quite sure this will be resolved with time. By resolved I don’t necessarily mean that everything will become symmetrical across the ports, just that acceptable performance will be possible in every scenario - in many settings the problem doesn’t present itself
In terms of CPU power, the ax2 is to the Refresh, as the Refresh is to r3, so it is a significant increase. It can handle roughly 1 Gbps even without fasttrack. (I’m not suggesting disabling it, just saying…) So in terms of CPU and configuration it certainly can serve as both an AP and the router. (In fact as far as I’ve seen, this is not at an uncommon setup - I used it like this for some time.)
For roaming, capsman is needed. If it runs on one of the APs, the local interfaces of this will have to be configured locally (but this is just setting the local wifi interface to the same configuration as what would be pushed to it were it a slave - so three clicks or so.) Even though in this case the local radio is not “controlled by capsman”, this is the exception to the rule: in terms of roaming it participates fully, the same as if it were in fact managed.
The rest is up to you: is placement/cabling suitable? This only you know.
My personal opinion can be gleamed from the above: I used my network like this without any sort of problem. Some people are of the purist opinion that having one “central” router reserved for only this function is better, but in my view - other than being “pure” - there’s really not much benefit.