why ROS NO 2 CPU
why do you need this? RouterOS runs very good with a P4 or Xeon single CPU system
I need it to 
or my customers need it.
//Rickard
Yes it’s already been asked for.
Last time, MT said they’d look at it.
IMHO it’s inevitable:
Look at all the new AMD and Intel releases: no-one is pushing up clock rates any more, they are pushing up the number of cores.
The latest Intel one (announced last few days) is up to 4 cores.
And then there are other people with dual CPUs on one board (subtly different) such as Via.
And we all know, internet bandwidth demands (hence traffic through routers) aren’t exactly going down … 
Hope MT developers are secretly working on this as we talk …
Just throwing this out for the discussion … what part of ros specifically would multicpu help with? Are there bottlenecks in the routing process? Or is it the packet filtering engine? Or is it wireless?
I for one would think that running processes on a single cpu but allowing affinity would be a big help… run the RIB updates in one CPU whereas the actual routing process is on another.
Being able to see a process list on ros with the individual affinity settings would be cool… that way the end user can determine how to split things up themselves. You can also get around having to make every process use both cpus, you just allow them to choose which one it runs on.
I know multithreading certain things is almost impossible and creates more overhead that worth sometimes, but allowing affinity would really cool. Just my thoughts - I have no idea about the internal working of ros and whats possible. It is my most favorite platform : )
Sam
Yup you are right, the fundamental question is
“how well can a router be split up to share workload amongst multiple cores ?”
I don’t know the answer either, except that I know certain network processors used in terabit core routers do have multiple CPU cores to handle ingress/egress of traffic from line cards at 2.5/10Gbps etc.
The only people who can answer this one are at Mikrotik …
The way thing are going these days is ASICs. Products like Extreme Networks that does true wirespeed routing up to 10G only has 3-400MHz CPUs that does administrative tasks and control. All the real work is done by dedicated circuits and i believe this is the future as ASICs has become programmable and therefore offers the same flexibilty as a CPU based software routers like MT. I think the coming generations of Routerboards will prove this. We’re allready seeing Wireless cards handling encryption etc by themselves and i wouldn’t be surpriced if i see a dedicated chip doing routing/traffic shaping on the next Routerboard generation, maybe even cheaper than what we have today…
Just my 2 cents..
Regards
Henrik Pedersen
Interesting discussion …
Those are hardware-based routers, where as MT is currently pure software - 2 ends of the scale
The benefit of the RouterOS concept is flexibility (i.e. software upgrades), lower cost of development (vendors like HP, Extreme invested $10m’s in ASICs), shorter development cycle time, and wide choice of existing CPU platforms.
There are “middle ground” solutions using large FPGAs which nowadays even have powerPCs embedded. But they run hot and are not cheap.
There are other solutions like “TCP offload” on new 10-Gig server NICs, and “encryption engines” to make VPNs run faster - these could be added if the developers wanted.
I’d be happy to be proved wrong, but I think RouterOS is going to stay a software solution so long as the cost/performance of off-the-shelf CPU power meets customer demand. Hence the topic …
anyway, in 2.10 we will have this and it has been said before. plus 2.10 is not so far away as you might think
and to both answers !
Most people could build 2 dual processor systems for the cost of 1 Xeon based system.
2 CPU IN ROUTEOS ？？？
YES OR NO ？？？？
So 2.10 will feature SMP for multiple CPUs/cores? Will it still be limited to 1GB RAM?
For small routers and networks, having MP/DC (dual-core) support as well as memory allocation control support isn’t necessary, but think of the following in largers networks and routers:
- Assign most functions to proc/core 1 and allow up to 256MB
- Assign BGP and the associated WAN ports with 1GB RAM to proc/core 2
- Assign (pick one or more) DNS/www/DHCP caching and xMB RAM to core 3
- How about 1 core running the system and one running a large hotspot and NAT?
- Assume that current model DS3 and OC-x cards get drivers, then those could actually have the power and memory to run. I say this as it seems that most of the “supported” devices are no longer in production.
Or, how about being able to just have a dual core system and divide the system RAM in half and then run as a live backup. This would allow one side to be upgraded and reboot keeping the other one live. Protection for a dead fan?
LOTS of options and capabilities. Being able to fully control the system would be most helpful.
Hope this helps to expand the horizons.
One reason MT gave for not making a list of running process available is that there are lots of features which share a single processes which would also make splitting them up between cores a difficult at least (Threads really shouldn’t be migrated between cores and the schedular usually tries its hardest to make sure this doesn’t happen for speed reasons).
Linux has a pretty good schedular (Better than Windows and arguably BSD as well as at least as good as Solaris) and good support for SMP (depending on the kernel version MT are using and how modified it is but both 2.4 and 2.6 have good SMP and scheduling) so there is no reason not to support it in some form.
The 1GB RAM limit really starts to hurt in dual-core/dual CPU systems where the RAM gets split between the CPUs. Linux has very good HIGHMEM support so there is no reason that >4GB can’t be supported let alone >1GB. The 1GB mark has to be an artifically imposed limit and while there may have been a reason for it in the past it is hard to see why it remains.
Another pain of the 1GB max limit in a SMP box is say you are using 2xOpterons and you give each one 512MB RAM to max out RouterOS. If you want to have that dual channel you need to find some 256MB sticks which are becoming rarer, particulrarly decent server grade stuff. You are also leaving a huge number of slots unoccupied which is just a waste.
As for splitting a system for redundancy I don’t know of any x86 CPUs that are able to run in AMP (Asymmetrical-Multi-Processing - It is mostly specialist industrial and automotive CPUs that are). The only way I can think of to do this is virtulisation (i.e. Xen - which I would actually like to see for reasons I outlined in another thread)
Hi,
any new informations about support multi CPU´s and 64bit architecture on MK?
Thanks
as usual … 2.10 …
we’ll see …
it’s already made into 2.10 … now just wait for it to be released sometime at end of summer
Wow good news … But I need dymamic routing …