I just finished reading very long thread about slow CPU in RB1100 on Czech ispforum.cz and then spent about 4 hours reading about ARM CPUs. The result is this:
ARM is probably the only future low-power hi-performance CPU architecture. Right now there is Cortex-A9 dual-core CPU running on 2GHz available with 10.000 DMIPS of procesing power with very low power comsumtion.
In around 2013 there will be available new Cortex-A15, up to quad-core 2,5GHz.
Dont get me wrong, but unless you plan to use that 16-core XEON you were talking about in RB1100 thread, what better low-power CPU than ARM are you going to use in future RBs? Some new PowerPC, like e600? Atom? Atheros AR934x or some new MIPS?
Either way, I wish you chose the best
Mikrotik RouterBoard 750, 433, 450, 493, 711, SXT are all ARM based.
Mikrotik RouterBoard 1000, 1100 are PowerPC based
Normis is being mean and hinting, you would think he is an Apple fan… I hope the product being hinted at is my April fools wish of a Cavium based RouterBoard
Yeah the Octeon’s are great, the Motorola AP7131 make use of them and they are blazing fast, you can even IPSEC the traffic from the AP back to the controller at wirespeed.
i’m sure that a super high performance with 2gbits or more wirespeed 64bytes packets with all features on, even its five thousands dollars or more will worth every penny. here we have a lot of space to use those type of routers! Mikrotik for the win!
I have an application right now where the client has 2x 100mbit and 1x 1gigabit internet feeds, im currently running the 100mbit links via a Mikrotik RB1100 and the gigabit via a large FortiGate as the Mikrotik simply could not handle the load. Ideally all three connections would go via a nice fast Mikrotik so I can administer BGP filters in one place, and use PCQ.
It’s going to have to be one hell of a CPU jump to handle that! the RB1100 is quite anemic when you consider everything. MT are gonna have to either bump the CPU speed/arch up quite a bit so it can handle 1gbit of traffic with real ISP rules in place. Either that or ASIC’s.
What would be nice is a SFP slot router with dual-core powerpc CPU, ASIC offloading of mangle/routing/encryption. 10-16 ports with wirespeed interfacing to the CPU (No more 2 groups of 5 ports with only 1gbit interface for each port)
Come on, you know that box is gonna have ASIC’s in it! We have a fairly well rounded range of lowend routers to pick from, whats lacking is a beast core router, There is clearly demand as users are trying to push 300+mbit on the RB1100 and getting loss, Give us a box that can pass 1gbit of traffic with a decent load out of mangle rules and contrack
We have customers running average of 1.2 - 1.5 gig of traffic running 3 full GigE BGP feeds running on a www.mikrotikrouter.com box. The v5 multi-core improvements have helped quite a bit as well!
Why did you decide to go with MIPS in the first place? I get how most high end MIPS (the 680mhz one you use for example) doesn’t need more than a passive heatsink vs the ARM’s and its fairly easy to get a hold of the shelf chips with a PCI bus, but why did you decide initially?
I only ask because I have been playing around with this ARM development board and just wondering if it be more fun to go with a fancy, yet more expensive, PowerPC chip.
MIPS is a strong and efficient instruction set with a bright future. If Mikrotik ends up needing more horsepower, they do have an x86 port that can chomp some serious bits with the right CPU and NICs.
They could switch to ARM down the road if it makes sense. I do believe that porting routerOS to ARM would be pretty straight forward, most specifically porting of drivers for various wireless cards and the nv/nv2 stuff. But that means another instruction set to support (MIPS*, PowerPC, x86 already).
I would certainly vote to NOT add another instruction set because the added dev time to maintain would cut into routerOS advancement. I would even suggest dumping the PowerPC stuff in favor of x86 atom, via, amd fusion etc. PowerPC is dead/dying and I suspect maintaining that branch if the code is cutting into our feature requests and bugfixes.