Work not evenly distributed among the multiple CPU cores

The device spec page for this device https://mikrotik.com/product/CRS326-24G-2SplusRM says wrongly that it’s a single core CPU.
We luckily have discovered in 7.0beta5 that it has in fact a dual-core CPU.

BUT: it seems the work is not yet evenly distributed among CPU0 and CPU1 as the following screenshot indicates:
CPU0 is doing more than 99% of the work whereas CPU1 does less than 1%.

Dear MikroTik developers, please fix this ASAP to end that injustice done to CPU0 :slight_smile:

Or maybe my observation is wrong. Is there perhaps another page or command to determine this (im)balance btw. the CPU cores?
CPU1_doing_not_much.png

Interrupt handling is not relevant information to judge how general load is distributed among CPU cores. My experience goes that interrupt handling depends on HW architecture as well, many x86 hosts service interrupts on a few distinct CPU cores, some even by core 0.

If you want to see if second core does its job, you have to run CPU profile.

Yes, you are right, indeed.
I’m new to RouterOS. Is it possible to profile the CPU load in RouterOS?

/tool profile cpu=all

Thanks. On my device it gives for example:

NAME C USAGE
www 0 0%
console 0 0%
firewall 0 0%
management 0 0.5%
profiling 0 0%
unclassified 0 99.5%
cpu0 100%
ssh 1 0%
unclassified 1 100%
cpu1 100%

But the following command says that CPU load is nearly 0%, not the 100% above. How to interpret these results? As x% of the CPUload% ?

/ip/firewall/filter> /system/resource/print
uptime: 3h11m2s
version: 7.0beta5 (development)
build-time: Feb/07/2020 11:56:32
factory-software: 6.44
free-memory: 458.6MiB
total-memory: 512.0MiB
cpu: ARMv7
cpu-count: 2
cpu-load: 0%
free-hdd-space: 3068.0KiB
total-hdd-space: 16.0MiB
write-sect-since-reboot: 122
write-sect-total: 5058
bad-blocks: 0%
architecture-name: arm
board-name: CRS326-24G-2S+
platform: MikroTik

I’ll guess: the unclassified includes idle time. But I may well be wrong.

Unclassified is on my MMIPS very quit and almost always zero. The ARM processor devices show often unclassified being maxed out when they reboot/crash.

Well, it is a beta version, on a hardware that used only one core with RoS 6. I think it is reasonable to expect some teething problems… Maybe it finds the extra core, but doesn’t initialize it properly?