This seems first time Mikrotik uses ARM cpu, will be packages for other boards based on ARM cpu? (like x86 package).
And other interesting thing is Power, it is written that it is 2x more powerfull than rb2011, but this is too little for that specs (dualcore cpu, 2 times higher frequency than rb2011). So why just only 2 times more powerfull?
I really hope that is 4x more powerfull than rb2011 as the cpu speed sugest 
Performance is not only a matter of clock speed. Actually, it is much, much more than that! Until now, the processors used in MT devices were more like ASICs. ARM is a general-purpose platform, which may not be as efficient in networking-related jobs, but can still perform them adequately and it is much more flexible than highly-specialized chips.
I would guess that this turn (which was rejected by Normis a few months ago but is certainly welcome!) was dictated by cost factors, the vast availability of code for ARM and possibly the future Mikrotik wants for Metarouter.
Kudos to Mikrotik for the choice! Quad core ARM boards would be even nicer, now that RouterOS is largely multithreaded. But we are just in the beginning…
I very much doubt that they will. MikroTik’s modus operandi when it comes to different CPU architectures has always been that they license software for generic x86 hardware (probably, at this point, more for historical reasons than anything else; I would be sad but not shocked if, at some point in the future, MikroTik discontinues the practice of licensing RouterOS separately from a hardware sale), but for all other architectures, it only runs on hardware that they make that uses that instruction set. As cool as it would be if they did so, as far as I can tell, MikroTik has no real incentive to try to make RouterOS for ARM run on “generic ARM hardware” since, really, there is no such thing. This means that if they did try to support ARM-based systems that other companies build, they would have to pick and choose which specific boards to support, and they would be spending huge quantities of time and resources to ensure that RouterOS runs on somebody else’s board flawlessly even though they have no assurance that they will sell a lot of copies to people who use those boards.
I would also guess that in conjunction with your guess about cost factors (and, perhaps more accurately, cost-to-performance ratio factors…I would not be shocked if, at this point, given the fact that ARM is very heavily used in mobile handsets, and that there has been something of an arms race when it comes to mobile CPU performance over the last few years as that market has developed, if an SoC based around ARM that cost about the same as a similarly-spec’d SoC based around MIPS outperforms the MIPS chip), part of this has to do with MikroTik’s good (?) relationship with Atheros (which, at this point, is the only 802.11 chipset family that RouterOS supports; MikroTik is in trouble if Atheros ever goes bye-bye), which at this point, as we all know, is owned by Qualcomm. All of the MIPS CPUs that MikroTik has been using since the RB1xx and RB5xx series were discontinued have been built by Atheros, but Qualcomm already had the ARM-based Snapdragon CPU line before the Atheros acquisition. Since MikroTik already gets their wireless chips from Qualcomm, it would not surprise me to learn that there is a Snapdragon CPU under the hood of the RB3011. I think it is also possible (though I readily admit I am just spitballing here) that Qualcomm may be starting to question why they are bothering to build both MIPS and ARM based SoCs when they could be making life simpler for themselves by standardizing on a single architecture across-the-board. MIPS-based Qualcomm SoCs may not be long for this world.
– Nathan
Except if… they actually decide to do that. 
I wonder, what if their ARM boards are not entirely custom-made, but based on some popular prototype with some additions?
ARM cpus are the future, have very fast development, power growth per year. They are made in quantities, so the price of made is low…
Now if we could get a routerboard based on AppliedMicro X-Gene ARMv8-A architecture. 4x 10Gb SFP+, 2-4 1Gbe interfaces, large amount of memory and 8-16 2.4GHz cores.
That would be the stuff!
There is no way that this is the case. Why would MikroTik suddenly subcontract the hardware design to somebody else when they have been making their own custom boards now for years? They have the staff and the expertise, so there is almost no reason for them not to use it. (Also, just look at the case design of the RB3011. Clearly it is in the exact same shape and has the same port layouts as an RB2011. That is only possible if they designed the RB3011 board.)
An ARM-based RouterBoard is also going to be using a port of RouterBOOT, guaranteed, and RouterBOOT does things a little differently than most other widely-used embedded bootloaders out there. RouterOS on platforms other than x86 is pretty closely tied to RouterBOOT, and RouterBOOT probably wouldn’t take kindly to being flashed to some random hardware that it was never designed to run on or recognize.
– Nathan
I for one would really like to see a 64-bit version of Router OS running on Intel CPUs (and VMware ESXi and AMD and on future Mikrotik products).
This is where the CPU market is rapidly expanding with low cost options and hi-end systems).
Wouldn’t it be great to have a Mikrotik multi-threaded 64-bit operating system supporting 256 Gig running full BGP tables - and OSPF and sitting at 3 percent CPU load with many many 10-gig interfaces supported with hundreds of vlans.
Wouldn’t it be great to see Mikrotik jump onto the virtual VMware bandwagon also and be known as the high-end router solution over a virtual or physical Cisco router solution.
I just don’t think there would be much work to do to support this environment and come out as the best solution for everybody everywhere.
unlikely thats suits for routers, yet, even with 14nm wafers produced SoC.
both A72(the only ARMv8A-based design, anounced, yet) and pervious A57 and A53 really hungry/hot.
but A53 cores was probably good start. relatively cold and relatively fast.
there was several multi-core and many-core(up to 64x in really mass-produced. all more ambitious ARM-devoted companies/design labs, shutdown, sadly) ARMv8 and ARMv8A -based chips, but they are REALLY hugry to use in networking.
as for smaller devices, with up to four cores - its could be decent entry for both SOHO and SMB market. bigger chips - bigger compelxity of design, especially in terms of heat dissipation and PSU/power circuitrty performance/reliability.
both Marvell and especially Qualcomm had quite Nice ARM-based SoC for networking(especially like Krait chips). more beefier are more suitable for dedicated IPS or storage/NAS, rather than generic router/CPE.
p.s.
for that price i was probably purchase one rb3011 “just from curiosity”. seriously.
but maybe its fit my home or work too(permanently). like bunch 450g’s, 751’s, 951’s 2011 did(&did good work) before.
thats would be long-awaited 2011 replacement. and 450g/850gx2 replacement of same platform/approach may get quad-core version of same chip. for extra $50-$80(with “extras” like 2x RAM and SD slot) in price or something alike in similar enclosure as 2011/3011 or 450/850 used before.
p.p.s.
about ROS over 64-bit x86 - more likely adoption of K12 chips from AMD(both full-scale APU’s and ULV chips follow later). originally they use improved A57 cores, but follow-up WILL use A72 and promised to be very cold and quiet.
Re: about ROS over 64-bit x86
Here is a big reason I would like to see “ROS over 64-bit x86” with vmxnet3 support:
#1 - a virtual “ROS over 32-bit x86” running MvWare ESXi using “e1000e” network interfaces - performing a bandwidth speed test to 127.0.0.1 = 14.6 Gbps
#2 - a virtual “ROS over 32-bit x86” running MvWare ESXi using “e1000e” network interfaces - performing a bandwidth speed test to a second “ROS over 32-bit x86” on a second VMware ESXi server with a 10-Gig Cisco switch in the middle = 9.7 Gbps
I would assume these speeds would only just get faster with 64-Bit ROS with vmxnet3 network driver support - and larger memory support for full IPV4 and IPV6 BGP tables.
In a virtual router server world, things will only get faster at time goes by.
North Idaho Tom Jones
no, you needs/purposes was clear, quite common among ROS x86 users, but there was conflict of interests and major purpose of ROS - sell it with hardware. so hardly we’re see x86 improvements soon, if at all.
while x86-compatible ARM drop-in replacements(like announced by AMD) mayd had more interesting future, sharing same ROS images/package due to same arch both in devices and in standalone/custom installations.
p.s.
maybe im wrong. but my impressions thats x86 wasn’t priority market for MikroTik team.
re: maybe im wrong. but my impressions thats x86 wasn’t priority market for MikroTik team.
I totally think you are correct - however it is still a huge market where profits could be made by Mikrotik with a router solution for the VMware ESXi platform. Even Cisco is already on the band-wagon - but Cisco is way expensive for any decent x86 32-bit or 64-bit virtual environment.
Also - I would kinda like to see Intel/AMD 64 bit multi-core CPUs with large amounts of ram/cache be considered for new high-end Mikrotik CCR products. There is a lot of cool new developments as newer very high-end CPUs come out every year from both AMD and Intel. - And there is a huge source of existing GPL code and compilers and programmers already available. Also - I think that for flat-out processing the Intel/AMD world is far faster than the ARM processing world - however you pay a price in Watts.
Let’s not forget the low power processors, e.g. Intel Xeon E3-1220L v2 - TDP 17W, 2 cores, 2.3 GHz up to 3.5 GHz, and others up to 35W, including eight core Atoms like the C2758 (4 integrated 2.5Gbps Ethernet, 20W, 2.4 Ghz), which all support 64-bit and could make a decent router with a decent power consumption.
Agree
What I am also thinking is, if we want high-throughput performance then power consumption is second. If we want energy conservation, then performance is second. Where CCRs are used, I would think that performance/throughput is the highest priority to achieve first.
North Idaho Tom Jones
maybe.
when SDN and OpenFlow become mature(about 1.5-2 years or so ? 
MikroTik move portions/all feats of ROS over it, instead of “bare metall”, kernel-based version and drop deprecated implementation of feats, w/o affecting b/w compatibility.
as for x86 “in general” - future ULV chips(esp Skylake and Carrizo) with 6W-18W TDP will obliterate MIPS/ARM/PPC chips with same termal package about 5x times and being multicore(and generally SMT too. while AMD rumored to had 4x threads/per core instead of 2x as intel does), but generally SDH boxes(universal/open or proprietary, OpenFlow/alikes-incompatible)presently VERY pricy/expensive. major concern was - relable SoC/CPU supply, cuz only two vendors mean you VERY vulnerable(VIA IP future still unclear), while MIPS/ARM/PPC chips available from nearly hungred of suppliers, many of which had own factories, even small/outdated/archaic.
second was price. and presently major, cuz x86 CPU’s remain very expensive.
so some consumers may build x86 gear for ROS, but MikroTik itself unlikely enter such market soon, or contribute much to x86 fork/branch of ROS polishing/fixing/improving.
thats why we’re lack 64-bit version of ROS and etc.
A question - I am not a programmer however I will ask: With x86 source code, are there re-writes of code to compile into a 64-bit ROS (so that more RAM memory could be allocated or gain additional CPU throughput) ?
Another question - is it difficult to compile for a different type of CPU. Lets say somebody comes out with a new super-fast 20 GHz 128-core 128-bit CPU but the instruction set is different. I would assume that first a compiler would be needed for the new CPU.
Just wondering …
its ain’t that simple, sadly.
and arch-specific things differ between x86 and 64-bit(AMD64/IMT64 arch) Seriously.
and properly-done kernels/firmware imply Many time spend in both testing, debugging, profiling.
its not “difficult”/impossible, but @#% of work if you do it Right.
some linux distros made/tuned/designed Especially toward this, mastering “consistency by design”, especially Gentoo and forks by rolling/devloping clean toolchain-based systems..
few config changes(global and local(in rare cases) ones), then you just re-build AnyThing for different arch(chrot or in VM) or with Different optimisation/priorities. generally, aside access to bigger RAM amounts there was fast IO and integer and FP computing speed beenfits, potentially on properly-profiled 64-bit x86 code(benefits on intel chips slihtly smaller, yet).
When it will be available?
RB3011 - when?
@normis: Any news about 3011 availability date? Q2 is ending in a few days and there’s still silent about release 