I’m pretty sure it was supposed to happen, why would SoC designer include two cores if it wasn’t?
Can’t say if current “solution” is permanent or not, but I wouldn’t be too surprised if eventually MT would find the actual culprit for instability and re-enable the second core. But probably this does take time and with current amount of outstanding items for ROS v7 they probably decided to postpone solving this problem.
OTOH I wouldn’t be too surprised if the second core remained disabled for next millenium or two …
98DX3336 is Dual Core while 98DX3236 that is used in this switch is single core in all sources I’ve found on the internet:
Marvell Prestera 98DX3336: Integrates 24 ports GbE, 2 ports of 10GbE and 2 ports of 20G stacking for Campus edge/access with a dual core ARM v7 CPU
Marvell Prestera 98DX3236: Integrates 24 ports GbE, 2 ports of 10GbE and 2 ports of 20G stacking for SMB/SME edge/access with an ARMv7 CPU
armada-xp-98dx3236.dtsi:
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
armada-xp-98dx3336.dtsi adding one extra core:
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
Did you find anything else that suggests two cores in 3236?
Same trouble. mipsbe
I have the same issue, it would appear to be an issue with .default-originate=always function if you set to .default-originate=always. if you set to .default-originate=never or .default-originate=if-installed then issue is resolved.
Doesn’t help much but shows where the issue is.
And you don’t have anything to suggest there aren’t two cores in that SoC.
As to the part of “functional” … that’s debatable 
I’ve posted above how current linux kernel treats those two SoCs, that’s more than you’ve put to the table.
And those two lines I’ve posted can be found browsing marvell.com from 2017:
https://web.archive.org/web/20171220010242/http://www.marvell.com/switching/prestera-dx/
again, i’ll post them here:
Marvell Prestera 98DX3336: Integrates 24 ports GbE, 2 ports of 10GbE and 2 ports of 20G stacking for Campus edge/access with a dual core ARM v7 CPU
Marvell Prestera 98DX3236: Integrates 24 ports GbE, 2 ports of 10GbE and 2 ports of 20G stacking for SMB/SME edge/access with an ARMv7 CPU
@Znevna: seems you’re right. Also this article corroborates: https://www.linleygroup.com/newsletters/newsletter_detail.php?num=5159
So I really wonder where that second CPU core came from?
Probably brought up by mistake, but did anyone see it doing anything? besides creating problems..
If it wasn’t there to start with, what would it possibly be doing ?
In one of pages (and I can’t find it now) the text was written in a way that might lead some people believe it’s got two cores. At the same time it could be read as if CPU implemented sort of hyper-threading. If the second is the case and linux kernel devs (at certain time) treated it as dual-code CPU, this might explain some problems.
Weird thing is, this pdf lists them as dual core:
https://download.datasheets.com/pdfs2/2020/5/19/14/46/6/78966/ms_/manual/essors-armada-switching-prestera-solutions-guide-2015-02.pdf
Just run a search for 98DX3236 and You find it. At the very end, just two matches - one with a quad core solution and another with a dual core.
As for the number of CPUs: The kernel just keep couting what it sees - there is no magic there. Sure, it needs to know the architecture. Sure, if it doesn’t know the CPU it says that. But it counts the cores all the same.
Just for fun I just created one VM with RoS 7.4beta2. The real CPU is one Rysen 3600X - six cores, twelve threads. I attributed the VM 26 cores. And that’s what RoS thinks it have.
Because the kernel just counts the number of cores presented to it.
“It can’t be! They changed it and the number dropped!”
Yes, it can. For two reasons. Well, three.
- Ok, ok. You MAY be right. I doubt it, but maybe it only has one core. I don’t believe it, but I’m not always right. So…
- They patched the kernel, and it introduced a bug - leading to count one core as two. Again, I don’t think it’s this.
- The kernel have one option, enabling multicore/processor support. Yes, it’s true. Well, at least it had it, when single core CPUs where what we had, and servers used multiprocessors and/or single/dual core. Disable it, and the kernel uses only one core. Enable it, and the kernel uses all the available cores/processors.
I think they are having problems with dual core - some racing condition, analog to the reordering packets on the Tile CPUs - and found out that using only one core solved the issue.
I hope they fix this, and get back to using two cores. But since this is sold as single core, we can’t say they are cheating the consumer…
If you’re so familiar with this subject, please explain the two files above that I mentioned: http://forum.mikrotik.com/t/v7-4beta-testing-is-released/158543/1
Why did they bother creating another file for 3336 specifying just one extra core if the kernel is so smart figuring it out on it’s own?
Could it be that x86 and arm are two different beasts? no? nah, didn’t think so either.
Thank you.
Paternot:
So you mean it’s a bug of linux kernel or Mikrotik OS?
Because several things are declared to optimize it further.
One example:
When Intel started using HyperThread the Linux kernel interpreted each CPU (there weren’t multicore designs at the time) as two. It lead to problems with the scheduler, since the system tried to consider each thread as a single CPU. When You where running a single socket machine it didn’t make much difference - but with two or more sockets it did. Why? Because with a (say) 2 socket machine You had 4 threads - 0,1,2 and 3. When running two heavy threads one should put one thread at each CPU (so, threads 0 and 2), instead of two threads on the same CPU (like 0 and 1).
Without this optimization the kernel still worked, and still thougth it had 2 CPUs for each socket. With the optimization it worked better.
Another example:
Now the x86 CPUs are able to boost beyond their clock speed. Basically an auto overclock. AMD CPUs usually have one given core that goes further up, but until very recently Intel had a simpler boost, and all cores would go up to the same clock. But they would slow down, after some time, due to thermal throttling.
So, we had ANOTHER optimization - that was used on a per CPU model basis: The kernel would cycle the load through the cores (taking care not to use two hyperthreading from the same core), in order to let them cool down. Without this optimization, the kernel would work - but You would loose speed on a single threaded load scenario.
Now, get down from your high horse, and learn to debate in a civil way. Just because You are rude doesn’t mean we have to put up with it.
I don’t know. I think maybe. I don’t think the kernel would find another CPU that wasn’t there. It could be something like hyperthreading, but I don’t think these CPUs have it.
I do know that the Tile CPUs (the smallest of them with 9 cores, and going up to 72 cores) had one interesting problem: if the routing engine used more than one core to route single connection, the packets would get out of order at the other side. Mikrotik solved this making the routing of a single connection single core. This is why the Tile routers are great dealing with hundreds of slower connections, but quite awful dealing with one single very fast connection.
I think we have something like this here: with two cores there were flapping problems, with one core they are gone. Looks to me like a timing problem. It probably can be solved with more work on it - but I believe stabilizing RoS V7 ir more important now. It is a switch, after all. The second core will not make any difference while processing the L2 traffic.
I well know that I have to draw it out for you to make you understand that you are wrong, considering our past interactions: http://forum.mikrotik.com/t/hex-block-diagram/114819/14
You only dug up some even older document that claims nowhere that 3236 is dual core (but it states somewhere that some cpu has 800GHz speed, legit so far) and you’re talking about x86, again, which has nothing to do with arm or this particual SoC.
So I’ll get down from my high horse when needed
Cheers!
Paternot:
Thank you for nice explanation mainly for 72 core.
Ah. Just trolling, then. Ok, carry on.
It would really be cool to get a somewhat more descriptive statement from Mikrotik regarding the CPU core topic …
Does it matter really? It’s the software threading model used by things in userland that matters. And the kernel’s scheduler take into account a variety of things beyond “core count” in how it divides CPU tasks.
Perhaps there is a bug in how the CPU’s capacities are translated into RouterOS attributes in CLI/winbox, but it’s not like there is some hidden switch they aren’t turning to use the “all of the CPU”. Their software utilization of the kernel is way more important, and that manifested directly in network speed so not much to document about “core count” & actual traffic results would speak louder.