For what is worth, find attached a spreadsheet with a quick comparisons of the specifications of the two "plain" Hex's and of the two Hex_S's.

The new Hex S (2025) seemingly has exactly the same architecture/block diagram as the Hex refresh (with the added SFP, of course).

If/when the known issues with ether1 on the Hex refresh (that likely will affect also the SFP on the new Hex S ) will be solved, it seems like a winner in several aspects.

It seems to me that (again if the performance will be adequate) - while being a no brainer replacement for the traditional Hex S, costing 10 dollars LESS , it represents for only 10 bucks more a very serious competitor to the "plain" Hex refresh E50UG.

While the 20 dollars difference between the old models Hex and the Hex S was relevant, in practice the good Mikrotik guys halved the difference between the new models, and the S is 48V/802.3af/at compatible.

I would be happier if they changed the default firewall rules.........
add action=accept chain=input comment="Users & Admin to Services" in-interface-list=LAN
add action=drop chain=input comment="drop all else"

add action=accept chain=forward comment="internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="port forwarding" connection-nat-state=dstnat disabled=yes { enable if required or remove }
add action=drop chain=forward comment="drop all else"

but yes, the plain 50, will have short life span if for only $10 more buck one can throw in a 2.5 port.

it seems like a winner in several aspects

Not sure... If you look at the theoretical (!) throughput numbers (https://mikrotik.com/product/hex_s_2025 ... estresults)
It can "only" hit 1.4Gb/s. In practice will probably be less.

Hence that 2.5Gb port is kind of overkill for routing usecases.

The speed declared Is exactly the same for the hex refresh and for the new hex S.
(same chips and block diagram)
For ten bucks more you get a SFP cage and 802.3af/at compatibility.
Even if the real throughput of the SFP is only 1 GB, It still is one port more than the plain hex (refresh).
Of course if the 2.5 Gb behaves like the ether1 of the hex refresh , working in practice at 1/5 or less than the expected speed, if until yesterday Mikrotik had a problem, starting today they would have two problems.

Interesting, in the video they specifically talk about using the SFP port with 2 Gbps ISP connection. I suppose for large packet size + FastTrack it will reach that indeed (3646 Mbps listed). Another potential use is local connection to something like a NAS. Pity the SFP is not switched in hardware but with software bridging should reach 2.5 Gbps according to specifications.

Another minor but useful improvement is ARM 64-bit. I don't run containers on routers but heard it's difficult to find 32-bit ones.

For ten bucks more you get a SFP cage and 802.3af/at compatibility.

I agree, it seems like a killer of the regular hEX. It's actually $9 (69 - 59.95). Would be interested to see reports on eth1 and SFP performance in real life.

I wish they didn't use CPU-bound eth1 for PoE-in, since it's a candidate for trunk uplink. And even without any issues the link is limited to 1 Gbps, no good for a trunk.

what a nonsence upgrade again... 2,5 GBit SFP and CPU is able route not even 1 GBit... I can not imagine how to use this device? Is it swtich with SFP? Why they cll it router when it has no CPU power to bz a router for 2,5 GBit?

Why hEX-S use 64bit arm64 and HEX refresh still use 32bit armv7 , they use same SoC .

I also find the arm/arm64 difference really interesting.

Also, the link in "Support and Downloads" points to the arm64 package, but the "Test Results" part seems to be copied over from the "hEX Refresh" verbatim - I mean the throughput is expected to be similar, but not to the last decimal.

At least according to getic.com, these devices are shipping. Does anyone actually have one?

There are apparently some problems with the separate (ether1) port on the Refresh model in some configurations (as detailed on this forum and elsewhere.) I have no proof, but my guess is that this is related to some sort of driver problem. It would be really interesting to see how this plays out on the "S".

Also I would expect a boost in software crypto throughput for the 64 bit software, which makes the difference between the two models very interesting, given their *very* similar price points... I always thought the decision to run 32 bit versions on 64 bit systems was because of the difference in RAM footprint, but with 512 MB it is clear that these device can handle the 64 bit version.

I can not imagine how to use this device? Is it swtich with SFP? Why they cll it router when it has no CPU power to bz a router for 2,5 GBit?

Just read anserk's comment right before yours.

I read somewhere here on the forum about the E50UG that the chip is 64-bit while the OS is 32-bit. I wonder if this note from documentation is still valid even for hEX S:

For devices with EN7562CT CPU like the hEX Refresh, only arm32v5 container images are supported, meaning a limited number of containers can be run.

https://help.mikrotik.com/docs/spaces/R ... quirements

The note implies this is a chip limitation. Also, the plural form ("devices") used at the time when no other EN7562CT devices existed makes me think the new hEX S still won't be able to run 64-bit containers. Or maybe 64-bit is just a chip feature that can be enabled if selected during production (kind of like selecting how to use PCIe lanes available on x86 chipsets).

Why hEX-S use 64bit arm64 and HEX refresh still use 32bit armv7 , they use same SoC .

I doubt the hEX S refresh will be running 64-bit RouterOS.

The original Youtube video about the hEX refresh, as well as the original brochure, both talk about "64-bit ARM". But then MikroTik walked that back later. The current version of the hEX refresh brochure is nearly identical, but they scrubbed all references to "64-bit" from it, and added an "EDIT:" comment to the Youtube video description clarifying it will run in "ARM32 mode".

If you look at the hEX S refresh brochure, it also doesn't mention "64-bit" anywhere on it. It's only on the main Specifications tab of the product description where it says anything about "64-bit". I have seen MikroTik make mistakes before in the specifications, and I expect that they will update that to remove any reference to "64-bit" from it, to match the regular hEX refresh. This mistake was probably just a hold-over from whatever was going on with the non-"S" model in the early days of putting together its marketing materials, since it's almost certain they were both developed in tandem.

I am having a hard time actually coming up with any concrete information about this SoC. Like the last hEX, it's another MediaTek part, except that it is being marketed under their subsidiary Airoha, who publishes no datasheets on it (at least as far as I can tell, on the publicly accessible part of their site). Since it seems to be a relatively new part, it would be shocking if it were not 64-bit. But both of these I think are the first MediaTek-based products using ARM instruction sets that MikroTik has manufactured, and so perhaps there is some limitation in the SoC that prevents it from being able to run the ROS7 ARMv8 binary code (missing some instructions?), and they aren't willing to make any compromises in how they build the ARM64 package to accommodate those limitations or to build and distribute a second "type" of ARM64 package (admittedly would get confusing), so they opted to just have it run ARMv7 code instead? Honestly, for a little $60 router, it's hard to argue that it's unreasonable, although I can understand the disappointment...

I can confirm hEX S (2025) uses the arm (32-bit) architecture just as the hEX (2025) and does not use the ARM64 architecture as mentioned in the product page.

Thanks for reporting. Have you had a chance to test eth1 port performance? E.g. plugging in eth1 with default configuration to your LAN switch, plugging in a laptop or a desktop to eth2-5, and running iperf3 tests should be enough to see if it suffers from the same issue as non-S variant.

Why would it be different ??

Why would it be different ??

Because it's another device.

Thanks for reporting. Have you had a chance to test eth1 port performance? E.g. plugging in eth1 with default configuration to your LAN switch, plugging in a laptop or a desktop to eth2-5, and running iperf3 tests should be enough to see if it suffers from the same issue as non-S variant.

So far, I haven't been able to reproduce the problem reported here. I connected an RB4011 to ether1 (directly connected to CPU) and my laptop to ether5 (connected to switch chip). I get 945Mbps both in TX as in RX when testing from the laptop using btest.exe. This is with the default (out-of-the-box) config and using RouterOS v7.18.2. I also tested v7.19.1 and see the same results. I see ~840Mbps when I disable FastTrack.

Why would it be different ??

Because it's another device.

To be fair there's a really good chance that it uses the exact same PHY with the same connection to the SoC. I don't know if you're willing to get out the screwdriver and magnifying glass, but I'd bet a soft drink that the chip used for ether1 is the EN8801, and the one for the sfp is the optical version of the EN8811. EDIT: It would also be my guess that the reason why the SFP port is 2.5G capable is that the EN8801 (1GbE) is only available in copper, while the EN8811 (2.5GbE) is the one available in both copper and optical (SerDes) versions.

Thanks for reporting. Have you had a chance to test eth1 port performance? E.g. plugging in eth1 with default configuration to your LAN switch, plugging in a laptop or a desktop to eth2-5, and running iperf3 tests should be enough to see if it suffers from the same issue as non-S variant.

So far, I haven't been able to reproduce the problem reported here. I connected an RB4011 to ether1 (directly connected to CPU) and my laptop to ether5 (connected to switch chip). I get 945Mbps both in TX as in RX when testing from the laptop using btest.exe. This is with the default (out-of-the-box) config and using RouterOS v7.18.2. I also tested v7.19.1 and see the same results. I see ~840Mbps when I disable FastTrack.

Again, this is just an educated guess, but the problem seems to be *not* that the CPU runs out of power, but related to situations in which flow control would be required. I consider it a clue of some significance that even the counters for RX and TX pause are totally absent for ether1.

Thanks for the testing and reporting! Are you otherwise satisfied with the device?

Why would it be different ??

Because it's another device.

I see your point.
Just to be sure, I opened my Hex Refresh.
No provisions at all for additional components that I can see at first sight (read: not for the obvious things like SFP port or POE Out) so at least the circuit board itself is indeed expected to be different from HEX S Refresh.
While the block diagram is identical (except for that extra SFP connection), PCB wise it's different enough then.

If you tested your device and see no limited performance, then it's really odd why Hex Refresh has this problem (I may have to rerun some tests with mine).

If you tested your device and see no limited performance, then it's really odd why Hex Refresh has this problem (I may have to rerun some tests with mine).

That problem with RX throughput on ether1 of hEX refresh does not seem to be universal...some people have the problem, some people don't. It's not clear yet exactly why. Some have speculated it may have something to do with some weird interop issue with the device it is uplinking to, as at least a couple of people have put a dumb switch between their hEX and their ISP uplink, and "fixed" the problem that way.

So just because @FezzFest has not seen the problem with his hEX S refresh does not mean it doesn't have the problem, or that MT changed something between the two designs that would account for or work around whatever that issue is. It could just be that he was lucky, and wouldn't have had the problem with the regular hEX refresh either. The only way to know for sure would be to take a hEX S refresh over to somebody who has a hEX refresh and who is suffering from the problem, and have them swap out the hEX for the hEX S with *identical* programming while placing it in an *identical* situation (plugged into the exact same internet connection, etc.), and see if the problem still happens. So we will have to wait for somebody with a poorly-performing hEX refresh to "take one for the team" and order an S to try out.

Either that, or wait for there to be a larger sample size of hEX S owners who can weigh in. If literally nobody with the hEX S comes forward with this same complaint after it has been on the market for a few months, then perhaps it dodged that bullet after all...