Is there some insights when 64bit version of x86 can be released? Date ?
We cannot use CHR as there will be enough resources for our routers and we have issue with memory low or leak on quad channel motherboards.
Mikrotik should inject 64bit kernel into x86 6.37.3 version fast and fix some issues which appear after that … We know it is complicated, but in our opinion x86 is useless and mikrotik should switch to x86_64bit asap.
I as well wish we had X86_64 on the bare metal installs. I hate the overhead that a VM adds…albeit I will admit a lot of times it’s less than 5% total overhead costs. So for what it’s worth one can get 95% of the throughput of a VM. The problem I have is how to start a VM automagically if the system has a power failure. That and how to isolate out the local system from being accessible and only allowing the VM to be accessible.
Hypervisors start the VMs normally after the boot. Even vmware workstation does it if you switch the machines to shared ones. The selection of the hypervisor is on you.
Running the 32bit version bare metal on 64bit capable processors actually brings no penalties except memory addressing limit at 4GB. In some conditions it can even be faster (e.g. reading unaligned bytes, which happens often in network protocols on content dissection).
On the other hand, on 64bit you will get the dude server…
CHR do not offer satisfactory setup in our case in term of resources, install process and stability. We already tried. Also, there is issue if you use 10G interfaces. In x86 mikrotik every 10G card can have ALL Cores of CPU for processing. So if you use CPU with 8 cores, all 8 can process every such 10G NIC. If you use CHR, you have only one core per 10G NIC, which is terrible in performance. That is WHY, 64bit version of mikrotik is needed asap.
As 32bit offer possibility to use up to 4GB of RAM it will be maybe satisfactory, but 2GB which mikrotik see with 32bit version is very low, especially if there is more full bgp routing tables.
We see some strange memory leak also, but hopefully mikrotik support will handle it. Possible it is related to quad channel motherboard.
Anyway we need x86_64bit version asap. They should stop x86 and switch to x86_64bit.
CHR main advantages are the drivers.
X86 Mikrotik has a lot of problems with Hardware compatibilities which CHR resolves using virtual interfaces.
X64 Mikrotik would have the same problems.
Unfortunatelly, main disadvantage of CHR is performance at all and performance if you use 10G interfaces. We tested and with 10G CHR is not capable to do anything serious. On the other hand, x86 is capable to do it perfect in term of performance except limit of 2GB RAM.
We do not have issues with X86 except RAM and some memory leak. When RAM is limited to 2GB, you cannot have full routing table peering with more ISPs.
I would also prefer to run this on Bare metal rather than VM,
What real advantage do we get from CHR apart from more that 2GB of ram? I have not seen Fastpath or anything like that? We Run Proxmox / KVM and tried with virtio interface and vmxnet3.
Normis, we contacted support regarding issue in x86 with quad channel motherboard and ram leak. Last response by support was on 27.12. We also send supout files after that and no response.
Main issue with CHR is that is not capable to process 10G NIC with more than one core of CPU. We will send you pictures to support email as we already done it.
I also find myself not using virtualisation either. While i use a routerboard rather than x86, routerOS on TILE is 64 bit being able to address large amounts of RAM.
On x86 theres so much hardware that there is the issue of driver support however when it comes to linux, driver support isnt an issue if you could add drivers to it yourself rather than MT’s closed policy of not letting anyone mess with the linux bit of routerOS. In the past there were utilities that allowed you to use windows drivers for wifi NICs on linux as well.
The main reason why i dont use virtualisation is because the overhead of virtualisation is huge on memory performance, not for CPU performance rather. Since i use my servers for things like game servers, compilations and for massive parallisation virtualisation would hurt performance significantly as memory performance is needed for moving data between other things like GPUs, 10G NICs and such. On routing performance if you look at the CCR1072 it seems that memory performance does effect routing performance as well as shown on the benchmarks. For routing memory performance does matter when you are moving data at speeds significantly proportional to memory bandwidth. This means that if you are using DDR3 dual channel for a 1Gb/s connection, using virtualisation wont hurt but at 10Gb/s it can.
on x86, using a 64 bit OS is faster than a 32 bit OS, this is because of the extensions that allow multiple data to be processed at the same time. So by using 64 bits your instructions will be bigger but will still be fed into the CPU the same rate as if you used a 32 bit OS with 32 bit length data. So using 8 or 16 bit data on 64 bit x86 does not incur any penalty as x86 is a very complex instruction set with extended instructions to accelerate larger data processing focusing on IPCs. On GPUs however using 16 bit integers are slower than using 32 floats with the exception of nvidia’s pascal architecture and on AMD before GCN using 16 bit floats, not integers was faster than 32 bit floats.
I really think MT needs to look into how the linux distros get their drivers. A lot of vendors will willingly write drivers for routerOS as it uses linux as long as the difference isnt great. I suspect that part of the problem is that a number of drivers require libraries that routerOS will not include in its OS. a 64 bit routerOS for x86 will really be beneficial and people who see routerOS for the first time prefer trying it out on x86 in an office environment rather than buying a routerboard as they have servers laying around.
It sounds hard, but I think the only reason is “they don’t want”. As far as I know there is no technical reason why x86 only accepts 2GB. It just let sell CCRs better.