I see that the master/slave port has gone away in favor of a bridge. Does using a bridge in any way slow down or affect the speed of the network? Is this new way to handle master/slave ports better for speed, or the same thing? Why did Mikrotik make this change? I know it was already on the ccr routers, so I'm guessing it was for consistency. If anyone has a short explanation of the differences in speed and functionality between the old way and the "new" way I would appreciate it.

Thanks.

If the new bridge setup is simple enough, it will be hardware-offloaded so there should be no difference between old and new setup performance wise. However, if setup is not simple (adding VLANs to the mix is enough), it will not be HW offloaded so performance might be lower or RB's CPU load will be higher or both. This is true for all RBs with switch chip except for CRS3xx IIRC.
My guess is that MT went forward this way to unify configuration steps as well as to allow some functionality not present on switch chips. In switch chip feature list one can see that quite a few used switch chips lack some functionality or other and those can be offered in SW implementation.

We all certainly hope to see more HW offload support in forthcoming ROS releases.

When you say performance might be lower, do you mean lower than it would be the old way, or just lower in general not matter what way. I'm just wondering if the change has any negative effect, or it's basically the same thing just done a different way.

Thanks

What I observed on my RB951G is that if I configured it in new bridge vlan filtering way (so that HW offload was not possible) and did a throughput test between two ports, I did get wire speed, but CPU usage was higher than 90%. Meaning there's no reserve for another pair of wire speed transfers... not to mention routing and firewalling. When very same unit is configured in the switch chip way, it does wire speed while CPU doesn't notice anything and remains ready for routing and firewalling.
Newer routerboards with beefier CPUs will perform better, same test on hAP ac2 loaded CPU to around 50% of one (out of 4) core which leaves some reserve for other tasks.

As my setup involves VLANs I couldn't test new bridge setup with HW offload enabled, but I trust that in this way performance would be top notch with CPU load neglectable.

The new implementation offers at least same functionality as the old one ... which depended on switch chip implementation while new one does not. But, as I wrote, it does put huge burden on CPU and some routerboards just won't be able to sustain it.

What would be the minimum router board you would think for a large home with 20-30 devices? We have been using the hex routers and have had no issues. I think we need to think about something that will get us to 1gig wan to lan speed since gig internet is already out.

Thanks.

My guess is that hAP ac² would be capable of routing at 1Gbps. And any RB with similar CPU performance would do as well (current hEX probably as well). But current implementation of bridge, when using non-trivial functionality such as VLAN filtering, does not allow to use RB devices for switching tasks.
Then it's up to anyone's decission: either configure RBs in legacy manner (if number of wired ports on chosen RB is enough and switch chip provides needed functionality; current hEX is a fail here) and hope that bridge implementation will support HW offload of needed functionality at the moment when MT devs will remove possibility to configure switch chips. Or to get an ethernet switch (routerboard running SWOS or third party device). The latter might be the only option right now is some switch chip bug doesn't allow to use necessary functionality and bridge filtering doesn't provide needed performance.

Just ad a RB260GS to do all you VLAN Wirespeed switching, they not expensive and leave router to do routing. With this I suspect both the Hex and Hap AC2 will achieve 1Gb routing to WAN

just to be clear, if we use the hex with NO bridging, just a single wan port and a single lan port, and no vlans, have you ever tested to see if you could yet a gig wan to lan speeds?

We don't do much with vlans, so we don't really need to bridge.

Thanks.

I have not tested this yet on a HEX, but on a RB2011, I could get ~800Mbps download, which is a single core CPU running at 600MHz. The HEX is a multi-core CPU running at higher frequency, 880MHz to be exact.
The RB2011 has a single 1Gbps path between ports and CPU, the HEX has 2 x 1Gbps paths between Ports and CPU, so if you use eth1 for WAN, and either eth2 or 4 (not eth3 or 5) for your LAN, you will be fine.

Also keep in mind, the configuration of the device can also negatively impact performance, i.e firewall rules, etc.

why do you say to use ether 2 or 4 and not 3 or 5?

wait... I just realized I think you are not talking about the hex, right?

Was talking about the HEX specifically, the HEX as 1 x 1Gbps path shared between ports 1, 3 & 5 to CPU and another 1 x 1Gbps path shared between ports 2 & 4 to CPU if no switching is enabled

With the new “bridging” rather than port switching how does this effect what you are saying?

When you bring bridging / switching into the config, all ports switched/bridged will share 1 x 1Gbps path to CPU, so i.o.w:
For routing, if you have 1 WAN port, not part of bridge/switch group, it will have access to CPU at 1Gbps, and the other LAN ports that are in a switched/bridged group, will share a separate 1Gbps path to the CPU.

For switching, i.e. from LAN device to LAN device in a single Bridge, you will get wirespeed as the HEX does have a switch chip, although not a very complex switch chip. The same is not true for Vlan's as the switch chip is not Vlan aware

For a small home/office environment, I personally think the HEX is strong enough to handle VLANs using the software bridge config. If it does become a problem, then add a RB260 to do the Vlan switching on hardware level and the HEX for only routing.

Just remember, with a Vlan HW Offload capable device, that you will only get the benefit of Vlan Hardware switching for devices talking to each other in the same Vlan, if it crosses Vlan's, then it uses routing which must go via CPU anyway.

Hopes it make sense