Can't find the new E50UG hEX on the Mikrotik routerboard website. The link in the YouTube video has a brochure (https://mt.lv/hex_october) but it's a bit sparse.

It is an upcoming product.
the info are detailed in the PDF.

There is also a YT video
https://www.youtube.com/watch?v=Zrzq_zPWoQ4

Maggio, you should know better that pdf is useless as it doesnt denote the 512 byte information which is closest to real world performance.
Extrapolating from the 1518 numbers my guestimate with filter rules, the throughput should be in the order of 500Mbps, basically still not a 1 gig ISP contender.
It appears what has occurred is increasing the power/CPU of the hex series so it acutally matches closer to the very original original hex performance which was reduced when switching to RoS7.
The increased RAM will help overall performance. Also being an ARM64 CPU will open up more RoS applications.... ( like Wireguard!! etc.)

I'm pretty sure the difference in performance is more in line with what they claim then your estimations

BTW You could run wireguard on Hex since the start of ROS7... even on SXT LTE which has MIPSBE platform. (I know since I used those 2 devices in 2021 for a VPN link using Wireguard to vacation home in France)

What is now possible with this new version is Zerotier and BTH.

There is also a YT video
https://www.youtube.com/watch?v=Zrzq_zPWoQ4

That's where I got the PDF as I mentioned in the opening post.

I'm pretty sure the difference in performance is more in line with what they claim then your estimations

I'm with @anav here. The difference in test results between 512byte packets and 1518byte packets on some recent ARM devices (e.g. L009 or RB5009) is around 3-fold (PPS tends to remain almost constant) and we all know how test results relate to reality. So it's reasonable to expect around 500Mbps of real-life routing throughput from the new device. Which is actually not bad for a very versatile router with MSRP of $60.

Another very sad thing about the new device: it has passive PoE-in with input voltage range of 12V-28V. MT really should move to 802.3 PoE-in ...

Another very sad thing about the new device: it has passive PoE-in with input voltage range of 12V-28V. MT really should move to 802.3 PoE-in ...

On the other hand, it has 128MB storage! We will be able to partition it! YAY!

Yeah and you loose the sd card interface.

I'm pretty sure the difference in performance is more in line with what they claim then your estimations

BTW You could run wireguard on Hex since the start of ROS7... even on SXT LTE which has MIPSBE platform. (I know since I used those 2 devices in 2021 for a VPN link using Wireguard to vacation home in France)

What is now possible with this new version is Zerotier and BTH.

Thanks, for the clarification!! You trust MT Claims/fantasies, more than my facts ?? No maple syrup for you this Christmas, will send your bottle to MKX.

Next will be the improved hex S?

We need the sfp port and better ipsec performance, although I don't think the improvement will be significant.

I can't find any information on the Dual-Core EN7562CT 950 MHz Soc used in the E50UG. The raw CPU speed isn't significantly faster than the Dual-Core 880 MHz MT7621A in the RB750Gr3, but clock speed isn't necessarily a good indication of work rate.

Software support is the question here. I will be surprised if the bridge on the E50UG will be HW assisted and vlan aware as it is on the RB750Gr3 with v7.

Viktors downplays the importance of the "switching" feature in the video https://youtu.be/Zrzq_zPWoQ4?t=134 and at https://youtu.be/Zrzq_zPWoQ4?t=171 he says "the result, that depending on the config, we've seen performance even twice as fast".

So I will wait until more real world testing has been done to see whether this is really a drop in replacement for an RB750Gr3. Probably for most cases, the E50UG will be faster, but I will guess that there will be special cases where the RB750Gr3 will be a better choice.

I was really surprised that the increased non-volatile storage wasn't even mentioned in the video. I consider that to be a major advantage; the 16MB in the RB750Gr3 is too small for V7 if you want to load many packages.

Other things apparently missing from the E50UG vs the RB750Gr3 are the microSD slot and beeper.

E50UG pros vs RB750Gr3
Twice the RAM (512MB vs 256MB)
8 times the the non-volatile storage. (128MB NAND vs 16MB FLASH)
ARM64 vs MMIPS 32bit architecture (this is primarily a more features available thing, ZeroTier and BTH)

E50UG cons vs RB750Gr3
New SOC that may have limited support at least at first. Software may not be optimized as much as with older chips.
Switch support probably limited, probably will not support HW assisted bridging or vlans. So if that's an important feature, you may want to look at an additional external vlan-aware switch, but then there are probably better router choices (like the hAP AX^2 although it is also more expensive than the E50UG)
No microSD slot
No beeper

Looking at the PDF, there is one thing that worries me:

They declare this:
Max power consumption without attachments 4 W
Max power consumption 10 W

So far, so good. But the power supply sent with the device (as stated on the PDF) is one 24V 0,38A! If I'm not mistaken, it would have a limit of 9,12 W! This isn't even enough to power the declared maximum usage.

True, it isn't being sold yet. They may very well sell it with a 24V 0,5A power supply, and problem solved. But as of now, the matched power supply can't power it at 100% usage.

Mikrotik team,

When can we expect this new device to appear on your Web site with complete specs, block diagram and test results?

Any idea when it will become available for purchase?

Thank you

Another very sad thing about the new device: it has passive PoE-in with input voltage range of 12V-28V. MT really should move to 802.3 PoE-in ...

Reducing the range (the current hEX and many older products support 8-30V) makes it useless for sites with 12V float-charged lead-acid batteries which vary from 13.8V down to around 10.5-11V low voltage cutoff where the Mikrotik is powered directly off the battery to monitor the voltage. To handle 12V or 24V float-charged setups the range needs to be 10-28V.

There are similar gripes with other devices which do support 802.3af/at (e.g. RB5009, L009) as they state 24-57V, the minimum on a 24V float-charged setup is around 21-22V.

Other things apparently missing from the E50UG vs the RB750Gr3 are the microSD slot and beeper.

Aargh, no beeper?!? I am actually using the beeper/feeper for other people to stage hEXen 'blind', where the beeps and feeps indicate the stage and success or failure of the staging.

I noticed that too! It seems like the main website hasn't been updated yet with the new E50UG hEX, which is a bit annoying. I saw that brochure from the video, but it’s pretty barebones. I’ve had some luck in the past checking with distributors directly when stuff like this happens, since they sometimes get the details earlier than the website. Probably worth keeping an eye there.

...
True, it isn't being sold yet. They may very well sell it with a 24V 0,5A power supply, and problem solved. But as of now, the matched power supply can't power it at 100% usage.

These external power supply adapters are most common failure point of Mikrotik hardware. When devices with 24V 0,8A/1,2A adapters suddenly fall offline then first thing is to get spare adapter along before going to check out the status on site. For many years these have been the culprit for over 90% of these failure situations.

Yes I know that they are much cheaper than devices itself, but resolving these failures will cost more in labour than the cost of the adapter. These Mikrotik 800/1200mA adapters are officially sold for about 9€. It would be the time stop cutting costs on these.
P. S. It does not matter whether adapter is newer or older design. Both of them are prone to fail and most oftenly they are found dead after external power outages...

...
True, it isn't being sold yet. They may very well sell it with a 24V 0,5A power supply, and problem solved. But as of now, the matched power supply can't power it at 100% usage.

These external power supply adapters are most common failure point of Mikrotik hardware. When devices with 24V 0,8A/1,2A adapters suddenly fall offline then first thing is to get spare adapter along before going to check out the status on site. For many years these have been the culprit for over 90% of these failure situations.

Yes I know that they are much cheaper than devices itself, but resolving these failures will cost more in labour than the cost of the adapter. These Mikrotik 800/1200mA adapters are officially sold for about 9€. It would be the time stop cutting costs on these.
P. S. It does not matter whether adapter is newer or older design. Both of them are prone to fail and most oftenly they are found dead after external power outages...

This is a great point.

Do all MT devices use the same adapters (hEX, AC, AX, RB, etc.)?

If not, is there a chart of which adapters work for which devices?

If not, is there a chart of which adapters work for which devices?

Are you that lazy?? Checking the plain old hex........
...
.................

Rules of thumb:
1. voltage (dc output of adapter) must be an exact match for device input voltage ( or within the stated range if one is provided )
2. amperage (current) provided by adapter must be equal to or greater than expected device current input.
3. Polarity must match: Most common is centre positive.
4. (THANKS MKX) --> Plug Diameter: 5.5mm outside and 2mm inside diameter, female, pin positive plug, accepts 8-30V DC

Rules of thumb:
1. voltage (dc output of adapter) must be an exact match for device input voltage ( or within the stated range if one is provided )
2. amperage (current) provided by adapter must be equal to or greater than expected device current input.
3. Polarity must match: Most common is centre positive.

4. Plug diameter must match jack. As @Normis once wrote: all Mikrotiks use same dimensions of jacks (voltages vary though).

If not, is there a chart of which adapters work for which devices?

Are you that lazy?? Checking the plain old hex........

pwr1.JPG
...

pwr2.JPG

.................

Rules of thumb:
1. voltage (dc output of adapter) must be an exact match for device input voltage ( or within the stated range if one is provided )
2. amperage (current) provided by adapter must be equal to or greater than expected device current input.
3. Polarity must match: Most common is centre positive.

You're so right!

Hold on and I'll pull the power cable from the router so I can try in vain to get exact specs from looking at the plug, despite that info possibly already available....

<CONNECTION TO INTERNET LOST>

Hold on and I'll pull the power cable from the router so I can try in vain to get exact specs from looking at the plug, despite that info possibly already available....

No, not all RBs use same power adapters. They use at least 3 different voltages (12V, 24V and 48V) and within same voltage they use different power specs (or rather: current specs) ... I've seen anything between 0.38A and 2.5A. And then there are optional high-power PAs which are not shipped with any of devices but MT offers them never the less (mostly intended for PoE-out switches).

So when looking for a replacement PA one really has to investigate. Unplugging old PA is one possibility, visiting product page of the device with failing PA is another possibility (check both max power consumption as well as the PA which is shipped with device, product page usually includes this info). And when one wants to use PoE-out, also consider powered devicescand tgeir requirements (input voltage range is the most important).

As you can see, powering MT devices can be as complex as configuring them

4. Plug diameter must match jack. As @Normis once wrote: all Mikrotiks use same dimensions of jacks (voltages vary though).

It would be nice to know what the diameter is - and have it printed on the spec sheet. Also, I didn't know ALL Mikrotik devices - that had a round adapter - used the same diameter. Yes, Normis said - but I didn't see the post, and we have nothing online.

It isn't the end of the world, but would be nice.

It would be nice to know what the diameter is ...

Did you follow the link from my post?

I do agree that it would be nice to have it specified in all product brochures and product pages (in powering section).

Added as 4. to my post.

Well, several resellers provide this info (which is missing on Mikrotik power supplies official pages), example:

https://www.batna24.com/en/p/mikrotik-s ... pply-rmmip

Anyway, it is a "standard" 5.5mm*2.1mm DC Plug.

Should be 11 mm long, but I have seen in the wild slightly shorter ones (actually it is the plastic cover that may be a little excessive)

And (only as a reference):
viewtopic.php?t=121736

I love standards, there are so many of them.

I use these quite a lot, anything I buy gets swapped over to a multi 2.1-2.5mm plug, I did a couple of items last week, a new record player and my hAP ax2 which are now rocking this type of dual plug https://www.farnell.com/datasheets/2286781.pdf

Did you follow the link from my post?

I do agree that it would be nice to have it specified in all product brochures and product pages (in powering section).

Makes no difference: I wanted to know it one week ago, when I had to scavenge a PSU for one 5009. Didn't know the size of the plug, unit was being used and I couldn't power it off. I worked it out in the end, but had Mikrotik put this info on the specs my life would have been easier.

And you did ask support about it ?

I use these quite a lot, anything I buy gets swapped over to a multi 2.1-2.5mm plug, I did a couple of items last week, a new record player and my hAP ax2 which are now rocking this type of dual plug https://www.farnell.com/datasheets/2286781.pdf

Interesting hobby , voiding warranties of new equipment to make them "universal" .

Seriously, having handy in the toolbox a bunch of adapters *like* these (types 3 and 4):

is often a lifesaver.

And you did ask support about it ?

Didn't have to. Due to time constraints and possible actions, the issue sorted itself out.

But, really. They already have a page for each PSU. Would be that hard to just put the connector size there? The best solution would be to have this info both on router and PSU pages, but just on the PSU one would be good.

ŽThe best solution would be to have this info both on router and PSU pages, but just on the PSU one would be good.

IMO the info should be for devices. PAs are "consumables", which get replaced (with 3rd party parts) every so often, devices are not. Devices dictate voltages and nax piwer, not PAs. Now since MT devices all feature same jack dimensions, data about plug dimensions on MT's PAs don't necessarily have to be writren (one should assume tgat MT's PAs are physically compatible with MT's devices).

IMO the info should be for devices. PAs are "consumables", which get replaced (with 3rd party parts) every so often, devices are not. Devices dictate voltages and nax piwer, not PAs. Now since MT devices all feature same jack dimensions, data about plug dimensions on MT's PAs don't necessarily have to be writren (one should assume tgat MT's PAs are physically compatible with MT's devices).

If we put this info only in one side (either PSU or device), we still need to cross reference them, if looking for some part. It does me no good knowing that the PSU model 25 has the plug type "Y", if I don't know what kind of plug the device has. Yes, I could cross reference the original PSU model and find it out. But, really, is it so hard to just write "8 - 30V DC, plug 5,5mm" on the device page?

And even when buying third part PSUs: we need to know the plug.

About "...MT devices all feature same jack dimensions..." It isn't written anywhere, is it? Yes, yes. Normis said. But it isn't reasonable to expect someone to scourge the forum to get this kind of info. Not to mention that just because he said it more than 10 years ago it is still true.

Concur, lets put MKXs brain in an AI machine so we can siphon off knowledge of specific posts, when we need it 24/7 and 100 years into the future.

Having passive PoE-In instead of 802.3af is really disappointing.
This can be worked around but, IMHO, it spoils this device advantages when positioned as a plug-and-play device adding wired connectivity where cabling is not dense enough.

Hi,

and what about switch chip features of this previously unknown EN7562CT chip?

It is now on the Mikrotik Web site: https://mikrotik.com/product/hex_2024

You can find usual details, including the Block Diagram

The SoC appears to be from Airoha, and being a subsidiary of MediaTek I doubt there will be any useful information on the open web.

From the block diagram the switch chip is only connected to four of the five ports so it can't be used as a wire-speed 5-port switch, unlike all of the previous 5-port devices.

It's a change from old Hex, that's for sure.

1 port directly to CPU with a 1Gb pipe.
Then 4 ports to switch chip with a 4Gb pipe to CPU.

Ordered one for testing, will see how it behaves.

Fyi the switch chip is listed as a MT7621, the same as previous hEX, which supports hardware vlan filtering:

/interface/ethernet/switch print
Columns: NAME, TYPE
# NAME TYPE
0 switch1 MediaTek-MT7621

Fyi the switch chip is listed as a MT7621, the same as previous hEX, which supports hardware vlan filtering:

/interface/ethernet/switch print
Columns: NAME, TYPE
# NAME TYPE
0 switch1 MediaTek-MT7621

That doesn't seem right if it's the 2024 model. Can you run system/routerboard/print in terminal and provide the output (minus the serial number)?

It's effectively the case.
MT7621 is being listed as switch chip.

> system/routerboard/print
routerboard: yes
board-name: hEX
model: E50UG
serial-number: blabla
firmware-type: en7562
factory-firmware: 7.15.3
current-firmware: 7.17beta4
upgrade-firmware: 7.17beta4

hmmmm....that's an interesting way of doing things. Maybe that's a work in progress still. Thx for confirming!

Did some testing earlier, mainly to test wap ax but it was connected via vlan to hex refresh and then rb5009.

Pushed little over 900mbps via wifi, across that hex and it wasn't even sweating.
So vlan hw offloading must be operational already.
I think ...

Have to run those tests again and check parameters on hex to be sure.

Just reran some tests. While traffic testing and pushing about 1Gbps (laptop to wAP AX , UDP, over Wifi) , cpu on Hex Refresh was 0 to 1%. All ports have H indicator except for ether1 (which is to be expected with the new HW config).

I swapped the Refresh for the old Hex I have at my desk.
I used ether1 for a printer for now (low traffic), trunk uplink is ether2, wap AX is connected via ether3.

That doesn't seem right if it's the 2024 model.

Not really, basic switch chip functionality didn't change since ages ago.

And Qualcomm does the same: my Audience uses IPQ4018 SoC ... and switch chip reported is Atheros-8327. My venerable RB951G uses discrete ethernet switch chip type ... Atheros-8327. And I know it's not actually same chip, IPQ-4018 has a bug (VLAN tagging of PPPoE PADT frames doesn't work) while real AR8327 doesn't.

I guess that SoC designers simply take design of older (and proven) parts (if updated functionality is not needed) and "glue" them together ... (it seems that in case of AR8327 within IPQ401x they didn't simply copy-paste design, they optimized it and managed to botch it in between).

Just reran some tests. While traffic testing and pushing about 1Gbps (laptop to wAP AX , UDP, over Wifi) , cpu on Hex Refresh was 0 to 1%. All ports have H indicator except for ether1 (which is to be expected with the new HW config).

Thanks for the tests holvoetn, very interesting results.
I can't wait for mine to arrive...

Just reran some tests. While traffic testing and pushing about 1Gbps (laptop to wAP AX , UDP, over Wifi) , cpu on Hex Refresh was 0 to 1%. All ports have H indicator except for ether1 (which is to be expected with the new HW config).

I swapped the Refresh for the old Hex I have at my desk.
I used ether1 for a printer for now (low traffic), trunk uplink is ether2, wap AX is connected via ether3.

It would be interesting to know what the CPU load is when using ether1 for this amount of traffic

OK

Iperf from PC towards RB5009-iperf-container (to be sure wifi is not the bottle neck)

PC connected to ether1 on Hex Refresh, set as access port VLAN2: speeds peaking sometimes towards 500-600Mbps but rarely more, average 363 Mbps.
CPU around 20%

PC connected to ether4 on Hex Refresh, set as access port VLAN2: speeds normal for gigabit link, 950-ish Mbps, CPU 0-1% (so it's not doing anything)

So it seems that hEX, with refresh, got degraded from a decent 5-port ethernet switch to a decent 4-port ethernet switch with management port

Old Hex was already odd with its dual bus setup but what they did here is not really logical.
Hopefully there is some logic somewhere but I fail to see it.

For me no biggie, I have at least 1 device in my office/lab environment still happy with 100Mb.

One rationale I can think of:

for the primary use of old Hex, meaning router towards ISP device with maximum speed of 500-600Mbps, this is effectively an upgrade.
It has dual core ARM now (which allows things like zerotier etc to be used), more memory, more storage, and all other ports are now nicely on 1 switch chip.
I expect IPSEC performance will be at least on par, if not better (since same MT7621 is included).
I also suspect it will be cheaper to make then old Hex.

And let's be realistic, there are still a HUGE amount of places on this world where 500Mbps link is not even possible.
So it still fits right into that segment.

They have been doing it before.
L009 is a (sort of) drop in replacement for 2011 model.
I'm sure they will know what they do

I expect IPSEC performance will be at least on par, if not better (since same MT7621 is included).

Your expectation may be correct, but it's based on wrong premise. IPsec acceleration depends on CPU features or included accelerators ... but not on switch chip emulation. The new SoC EN7562CT includes clearly entirely different CPU (ARM this time), the only thing it seems (for now) to be carried over from older MT7621A is the switch chip. We don't know anything about other parts of SoC, whether they're also carried over or developed anew (or even missing).
I'd expect for IPsec acceleration to work already if it was so similar to MT7621A ... just like L2 HW offload which works already (as you found out yourself).

Then why are ipsec features listed as being tied to mt7621 on MT Help pages related to IPSEC ?
That's the main reason for my assumption. You may still be correct with your assessment, though.

If I find some time today, I may setup some tests between rb5009 and both hex models to see what happens.

Then why are ipsec features listed as being tied to mt7621 on MT Help pages related to IPSEC ?

Because back in the days MT7621 was referring to a single SoC with a single particular switch block and a single particular CPU. Now, for lack or anything more distinctive, it is used also to refer to the same switch block that is part of a different SoC that uses a different CPU

Then why are ipsec features listed as being tied to mt7621 on MT Help pages related to IPSEC ?

MT7621 is a SoC ... which includes CPU (MMIPS architecture), switch chip and some other things.
EN7562CT is a SoC as well ... which includes CPU (ARM architecture), switch chip (which is specced as EN7562CT model on hEX refresh product page but discovered as MT7621 by ROS) and probably some other things.

So if IPsec acceleration depends on CPU features, then we might wait for it get implemented/supported a little bit longer (do any of ARM devices have IPsec acceleration working yet?) ... if it depends on "some other things" in SoC, then we might have to wait a bit longer (for MT to get them supported[*]) or it might never come (if those "some other things" lack necessary support for IPsec).

[*] if ever. I'm still waiting for Qualcomm switches to get L2 HW offload from bridge, we all know all the necessary HW is there as it works when things are configured in ethernet/switch config subtree. I'm not holding my breathe though ....

do any of ARM devices have IPsec acceleration working yet?

It's not just a matter of the CPU architecture. There are ARM devices that do (hAP ac²) and that don't (CRS310-8G+2S+IN, wAP ax), and there are ARM64 devices that do (hAP ax²) and that don't (CRS304-4XG-IN). So as you said the particular SoC is what matters.

The EN7562CT seems to be some internal code of Mikrotik as Google can only find it on Mikrotik pages So no way to find out whether that SoC contains hardware AES.

do any of ARM devices have IPsec acceleration working yet?

It's not just a matter of the CPU architecture.

I know. IPsec can as well depend on some particular CPU instructions ... which may or may not be present in some particular CPU implementation ... this seems to be the case. OTOH necesary instructions could be available in all CPUs of some architecture but necessary support might be missing in ROS altogether (and if support was added at some point, all devices using CPUs of that architecture would get acceleration ... which is what my question was about).

A ARM64 CPU run at 32bit mode?

A ARM64 CPU run at 32bit mode?

Exactly same as AX Lite.
Also 64-bit cpu running in 32-bit mode.

Some rudimentary tests ...

Setup:
PC connected to HEX under test (old or new) -> ISP modem -> RB5009
Iperf test from PC to iperf container on RB5009

IPSEC over GRE (easiest to setup)
Old Hex: 154Mb down / 60.6 up (I did notice in the process tree a line called mt7621crypto)
New Hex, WAN on ether1: 66M down / 53 up
New Hex WAN on ether2: 54Mb down/57Mb up
My preliminary conclusion: IPSEC HW acceleration is not in effect yet. Or is there such a difference between a 4-core MIPS processor versus 2-core ARM ?

As a reference:
same setup with wireguard as tunnel on Hex New
176 down / 193 Up: CPU overall around 73%, 1 core around 80%)

So WG still rules, despite some not really liking it

The EN7562CT seems to be some internal code of Mikrotik as Google can only find it on Mikrotik pages

I did find a teardown of a TP-Link router for the Chinese market which uses it https://www-acwifi-net.translate.goog/2 ... _tr_pto=sc and in this case has external ethernet PHY to support 2.5Gbps interfaces.

It appears that the SoC has inbuilt gigabit ethernet PHY as the connections in the hEX are to the ethernet ports via the usual transformers, but no PHY chips. There are some pictures of the PCB on a distributors website https://www.roc-noc.com/mikrotik/routerboard/E50UG.html

It isn't a new SoC, originally produced by EcoNet before they merged with Airoha in 2021. The CPU is a dual-core Cortex A53.

My preliminary conclusion: IPSEC HW acceleration is not in effect yet. Or is there such a difference between a 4-core MIPS processor versus 2-core ARM ?

The old hEX is a two core job too - it just has two threads per core.

In tool profile it shows cpu0/2/3/3.

In tool profile it shows cpu0/2/3/3.

Yes, it does. But it's a two core, four thread job nonetheless.

Take a look at the specs:
https://mikrotik.com/product/RB750Gr3