What do you think is faster at BGP, an RB4011 or a CCR1009? By how much?
https://youtu.be/yxLWbUoFE-M
Thank you for the benchmark. The outcome of this must literally feel like a punch in the face for those business customers who bought the fairly expensive CCR1036 or CCR1072 models in the past. The new RB4011 seems to outperform the CCR-series in BGP convergence time - and that for just 200 bucks!
@MT: Multi-threaded BGP must be implemented more urgently than ever!!! Please make this your top priority for the next ROS releases. Why someone would need a 9/16/36/72-core Edge-Router when the BGP implementation can’t even utilize the hardware’s full potential?
Thank you for testing.
A15:
https://www.arm.com/files/pdf/AT-Exploring_the_Design_of_the_Cortex-A15.pdf
There’s some basic TILE arch info here:
https://en.wikipedia.org/wiki/TILE64
A TILE core seems to be very simple. A15 looks very complex.
The outcome of this must literally feel like > a punch in the face > for those business customers who bought the fairly expensive CCR1036 or CCR1072 models in the past.
Not at all. Things improve over time. The fact that it was released, the pricing level, this is a complement to using the MikroTik platform.
Improvement needs time, I agree, but many of the issues related to the routing-engine are known since at least 2012, the year in which the CCR-series and 6.x were released. Since then we’ve been told multiple times to just be patient and wait for ROSv7. Now it’s 2018 and still no significant improvements to the routing-engine have been made, no multi-threading thus poor convergence time. Buying a CCR feels like buying a Porsche while living inside Vatican City: not worth it because you can’t even drive faster than 20mph. Instead of throwing new hardware onto the market every few months, improving the existing software to better utilize the current hardware models would be the way to go.
Newer hardware is still needed because Mikrotik does not fit well all basic needs.
Of course it is, but throwing new hardware on the market still won’t fix any of the existing software-related issues and limitations.
Stop with the multithreaded BGP.
https://m.facebook.com/story.php?story_fbid=1432205596904888&id=186874744771319
Ok then what about a new CCR series with beefy x86 quad/hexa/octa/deca-cores 
Thanks this was great guys.Now if they could add some RAM , redundant PSU’s and some extra SFP+ slots I can finally junk these CCR’s 
Not going to stop at all. BGP processing and FIB updates definitely need to become more multithreaded. I have only 1 million routes in one of my CCR1036’s, thats only a single full table and some IX routes. Even at that level it takes 3-5 minutes to make it into the RIB and another 3-5 minutes before its added to the FIB. This is whether I’m adding a static route or waiting for a BGP peer to converge. Even small BGP peers i.e. customer ones with 1-5 routes still take 5-10 minutes for BGP convergence to happen. This is vastly different to single threaded BGP on Cisco, Juniper etc because they are more highly optimised and likely faster cores (and less of them) the TILE architecture has a quantity over quality approach (36 cores, 72 cores etc) so really needs to play to its strengths and be able to use the many cores to do these updates.
If the workload could be cut out to 72 threads we could be looking at <1 minute converge / update time.
Didn’t take the time to read the link, I take it?
Is it even possible to do table updates in paralel mode without causing some other issues? Why would EVERY manufacturer end up with single-threaded BGP?
I saw couple of research papers with experimental implementations of multithreaded BGP, but I am unaware of real implementation by any manufacturer.
Despite the fact I do not deal with BGP in my routers, I support your pursue of speed. However, if the request goes against nature of task, it simply can’t be fulfilled.
Some people don’t click on facebook.
Those without facebook. Actually Andrew has written it correctly. Here is what he says there:
My new response to people saying Mikrotik BGP being single threaded is causing them performance issues:
A few points:
Control Plane ≠ Forwarding Plane
While the processing of routing updates happens in a single thread, packet forwarding (the actual movement of your packets) is already multi-core capable.BGP is single threaded on Cisco IOS, IOS-XE and IOS-XR as well as on Juniper JunOS and Nokia SRos
The processing of routing updates, and in particular the application of route-filters needs to happen in a “run to completion” matter. That means that running it across multiple threads will result in unpredictable results. This is why you cant just “make BGP multi-threaded”. What can be done is to split each protocol to a separate process with a central “conductor” process, this is what Quagga/FRR do with the zebrad process, and what JunOS does with RPD.
Moral of the story…
We hope that Mikrotik is going to update the CCR line to support ARM processors. Tilera has had its day. At least we will get an immediate benfit in raw CPU power for the likes of BGP, firewall, routing etc..
I can only then presume that v7 or whatever you want to call it will be easier to code and implement as an industry standard CPU architecture is being used rather than a obscure Tilera architecture.
There was a thread of at least 6 months ago or more of what ports we would like to see on new “100Gbps” routers. Like I have being saying this is all conjecture without a roadmap from Mikrotik.
Yes, we are aware of this peculiarity and we are working also on new routers that have higher power per core, not just many cores.
Awesome! Please consider a new CCR with ARM, 12G-4S+ and redudant PSUs.
Would be ideal for smaller environments where you have fiber uplinks and access with copper.
Good 
Looking forward to them.