Community discussions

 
tabate47
Member
Member
Topic Author
Posts: 421
Joined: Wed Mar 13, 2013 5:23 am
Location: Los Angeles

Bridging and Speed

Sat Sep 15, 2018 3:44 pm

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.
 
mkx
Forum Veteran
Forum Veteran
Posts: 855
Joined: Thu Mar 03, 2016 10:23 pm

Re: Bridging and Speed

Sat Sep 15, 2018 4:47 pm

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.
BR,
Metod
 
tabate47
Member
Member
Topic Author
Posts: 421
Joined: Wed Mar 13, 2013 5:23 am
Location: Los Angeles

Re: Bridging and Speed

Sat Sep 15, 2018 7:49 pm

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
 
mkx
Forum Veteran
Forum Veteran
Posts: 855
Joined: Thu Mar 03, 2016 10:23 pm

Re: Bridging and Speed

Sat Sep 15, 2018 10:57 pm

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.
BR,
Metod
 
tabate47
Member
Member
Topic Author
Posts: 421
Joined: Wed Mar 13, 2013 5:23 am
Location: Los Angeles

Re: Bridging and Speed

Sun Sep 16, 2018 12:10 am

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.
 
mkx
Forum Veteran
Forum Veteran
Posts: 855
Joined: Thu Mar 03, 2016 10:23 pm

Re: Bridging and Speed

Sun Sep 16, 2018 12:08 pm

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.
BR,
Metod
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1014
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa
Contact:

Re: Bridging and Speed

Sun Sep 16, 2018 1:47 pm

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
MTCNA, MTCTCE, MTCRE & MTCINE
 
tabate47
Member
Member
Topic Author
Posts: 421
Joined: Wed Mar 13, 2013 5:23 am
Location: Los Angeles

Re: Bridging and Speed

Sun Sep 16, 2018 4:39 pm

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.
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1014
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa
Contact:

Re: Bridging and Speed

Sun Sep 16, 2018 5:25 pm

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.
MTCNA, MTCTCE, MTCRE & MTCINE
 
tabate47
Member
Member
Topic Author
Posts: 421
Joined: Wed Mar 13, 2013 5:23 am
Location: Los Angeles

Re: Bridging and Speed

Sun Sep 16, 2018 6:08 pm

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?
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1014
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa
Contact:

Re: Bridging and Speed

Sun Sep 16, 2018 6:20 pm

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
MTCNA, MTCTCE, MTCRE & MTCINE
 
tabate47
Member
Member
Topic Author
Posts: 421
Joined: Wed Mar 13, 2013 5:23 am
Location: Los Angeles

Re: Bridging and Speed

Sun Sep 16, 2018 6:23 pm

With the new “bridging” rather than port switching how does this effect what you are saying?
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1014
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa
Contact:

Re: Bridging and Speed

Sun Sep 16, 2018 9:13 pm

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
MTCNA, MTCTCE, MTCRE & MTCINE

Who is online

Users browsing this forum: nichky and 18 guests