The hAP ax lite and the wAP ax share the same CPU/SOC I.e IPQ-5010.
When looking at the Ethernet test results on the product pages, it appears that the wAP ax shows almost 50% better routing performance albeit caped by the 2x1Gb Ethernet ports.
What is the reason for such a large difference.
Not sure but looking at the block diagram of AX Lite, that switch chip in between ether ports and SOC probably has something to do with it.
For wAP AX there are 2 direct 1Gb full duplex connections to SOC.
All ports loaded at full speed results in 2Gb which is delivered as 2x1Gb towards SOC.
For AX Lite the 4 ports pass a switch chip which "only" has a 2.5 Gb full duplex connection.
So there is a bottle neck when all ports are being used (4x1Gb being squeezed into a 2.5Gb pipe).
Just guessing but if only 2 ports where used on that AX Lite, probably it would give similar results.
Interested to see if someone else comes up with a more logical explanation.
I'm only guessing here ... it could be that that external switch chip, driving the 4 ethernet ports, adds slight delay (after all, vast majority of swtich chips work in store-and-forward mode which adds some delay) which affects throughput (not sure if that would explain the difference seen between wAP ax and hAP ax lite).
And it could be that chipset is a bit "pimped up" in wAP ax ... in theory both devices should have identical 2.4GHz radios (as far as chipset performance goes) because they are both using IPQ5010 built-in radio ... but wAP ax specs say it's capable of outputing a dB or two higher Tx power. That "pimping up" in wAP ax is normally not needed for its routing capability as it will normally be used as simple AP ... but CPU power is necessary to drive WiFi data throughput up to the specs.
My working theory is that the IPQ5010, IPQ5018 and EN7562CT are all Dual-core ARM A53 processors clocked at 800-950 MHz, so they’ll all have very similar performance.
Although the routing throughput on some devices is bottle-necked by the SOC interfaces, what we’re seeing are Router OS v7 improvements and not differences in SOC capabilities.
On ealier devices, Routing 512 byte packets (25 ip filter rules) is approximately 310 Mbps i.e. hAP ax lite and L009UiGS
On later devices, Routing 512 byte packets (25 ip filter rules) is approximately 500 Mbps i.e. hEX refresh , wAP ax, LHG 5 ax, NetMetal ax, etc
Having said that, there seems to be a correlation between the lower speed and having a switch
Since we are all just guessing, I add my conjecture to the table. I don't think this is an apples to apples comparison. As @holvoetn mentioned:
As @mkx mentioned, adding switches in series can cause slight delays due to store and forward, but in a traffic generation case, once the "pipeline" gets filled up, it shouldn't affect total throughput. But this applies to any end to end delay including propagation delay, so I would think that is generally a non issue for cases where ether of these would be used.
I also don't think they redo tests. For example the results for the E50UGS and the E60iUGS are identical, the only differernce being the model name. And they both say "EN7562CT 1G all port test". Are we to believe these were testing the real router boards, and they got two results that match to all printed (3-5) decimal places for every category? I don't. If you have ever done any testing, you will know that test results are not repeatable to that degree
.
Since test results are far below wirespeed (with small packets even below wirespeed of a single 1Gbps port), I don't think "pipelines" get filled.
OTOH it's a mystery whether tests were done while L2 bridge offload was available (and active). For a few devices (those which are classified as switches by MT), e.g. https://mikrotik.com/product/CRS326-24G-2SplusRM#fndtn-testresults , MT publishes both "ethernet - bridging" test results (which imply utilization of software bridge) and switching results (which imply setting things under /interface/ethernet/switch) ... and they are light years apart from each other. With L2 HW offload the gap between the two result categories gets blurry and it really depends on how that device is used - whether L2 bridge offload can do its magic to the fullest or not. And this can be different for every device model (and use case to certain extent), so results for wAP ax are likely not comparable to results for hAP ax lite.
Now, when it comes to routing, I'd expect that CPU performance (firewall rules evaluation) will be the bottle neck in any case, so it's still weird to see such a disparity between results for different devices utilizing same SoC.
After much pondering on this matter for too long, I decided to test for myself with the hardware I have, to provide some wider context. I used the following setup:
hEX S (2025) (EN7523 – dual core 950 MHz) Router OS 7.20.2
hAP ax lite LTE6 (IPQ-5010 – dual core 800 MHz) Router OS 7.20.4
2x Windows PCs with MikroTik Bandwidth Test v0.1
PCs were connected to ether2 and ether3 ports. Both ports on the same bridge but each in a different VLAN, bridge VLAN filtering on.
I played around with different packet sizes, TCP vs UDP, different directions etc. I've attached some screen shots from my tests below:
hAP ax lite - No fasttrack
hAP ax lite - with fasttrack
hEX S - No fasttrack
hEX S - With fasttrack
Based on my testing, I can confirm that there is not much difference in routing performance between the hAP ax lite and hEX S. The differences are broadly inline with the CPU frequency. During the tests one of the CPU cores was nearly at 100% while the other was between 30-60%depending on packet sizes.
With fast track and simultaneous bi-directional TCP traffic, I think the speed is maxed out as the packet acknowledgements etc do not add to the total.
As I suspected, the published test results on the hAP ax lite product page are out of date. Its performance should be in the same ball park as the later IPQ-5010/EN7523 devices. This shows how much of a bargain the hAP ax lite is.
