ARM crunching recommendations

[Dirk Broer]

As the hobby is expensive enough as it is, here some recommendations

32-bit
32-bit is on the way out. The bigger Linux distro's don't cater it for their latest (x86-64) releases and Android is dropping 32-bit too, as is IOS.
But you might have some special need for 32-bit, what to look out for in a tablet/SBC/smartphone/whatever 32-bit ARM device?

• First: the more cores the merrier. A dual-core is more efficient than a single core, a quad-core is more efficient than a dual-core and an Octo-core is more efficient than a quad core.
  Haven't seen any hexadeca-cores, or I would recommend them.
• Second: You need at least four Cortex A-15 cores.

In all my innocence I always thought that the 2014 Cortex-A17 was the best 32-bit ARM Cortex-A chip, but according to ARM the A-17 is mainstream, while the 2010 A-15 is high performance.

Based upon this the Odroid-XU4 might be the best choice for your money, running your 32-bit Linux and Android applications. The productivity of my Odroid-XU4 is on the same level as my Raspberry Pi 4B's that operate on 32-bit Raspbian at stock speed. The stock cooling of the XU4 leaves to be desired -both in performance and noise- and it could do with a leftover chipset cooler with heatpipe and fan. But, as already said: 32-bit is on the way out.

64-bit
64-bit capable SOCs we already had some years ago, but 64-bit operating systems -and BOINC applications catering for them- were less common.
Now there is both 64-bit Linux/ARM and 64-bit Android/ARM, and we are no longer confined to the somewhat mediocre performance of the Cortex-A53 based SOCs. In the 64-bit SBC userland nothing beats the Odroid-N2+ at the moment, having a hexa-core Amlogic S922X that can be overclocked to 2400 MHz for its four high performance Cortex-A73 cores and to 2000 MHz for the two low power Cortex-A53's. Be sure to order their 80mm fan too with the board, that comes with an immense heat sink. At the moment I only have an Android equipped N2+, but I'll order one to have Ubuntu Mate or Armbian soon too. Using the route of adding an alternative platform in the cc_config.xml you can let the 64-bit ARM boxes run 32-bit apps too. At least: This works with Linux, it ought to work with Android too. And when in doubt, always go for the model with the most RAM. If you do buy a Raspberry Pi 4, make it the 8GB version, so each thread can have 2GB. I sure would welcome a 12GB Odroid-N2++, that would be able to assign the same amount of RAM to each thread though.

For other 64-bit ARM devices: look out for at least four Cortex-A7x's. The higher the number, the better it is. And make it at least 4GB of RAM.

[Dirk Broer]

With 2023 almost knocking at the door, I give my updated recommendations

32-bit: Ditch them power-sucking beasties! None of them reaches to 10.000 or more credits per KWh...
You can always set your ARMv8 crunchers to crunch 32-bit tasks via

Code: Select all

sudo dpkg --add-architecture armhf
sudo apt update --fix-missing
sudo apt install libc6:armhf libstdc++6:armhf zlib1g:armhf libfuse2:armhf libgomp1:armhf libboinc7:armhf

to be sure you get all, edit you cc_config.xml to have these lines on a ARMv8 system

Code: Select all

<cc_config>
    <options>
        <alt_platform>arm-unknown-linux-gnueabihf</alt_platform>
        <alt_platform>armv7l-unknown-linux-gnueabihf</alt_platform>
    </options>
</cc_config>

Mind you: with the newest and latest upcoming ARMv9.2-A and ARMv9.3-A SOCs running 32-bit tasks will no longer be possible! (only applies when you are crunching on the very latest high-end smartphone: Cortex-A520, Cortex-A715, Cortex-A720, Cortex-A725, Cortex-X4, Cortex-X925)

If you run a 64-bit OS on a Raspberry Pi 3, or a 4 with 1 or 2 GB of RAM (perhaps even with 4GB), be sure to install ZRAM as well:
add the following lines to /etc/sysctl.conf (and then enable in real-time with the appropriate commands.)

vm.vfs_cache_pressure=500
vm.swappiness=100
vm.dirty_background_ratio=1
vm.dirty_ratio=50

To enable these settings temporarily without rebooting, use the following commands:
sudo sysctl -w vm.swappiness=100
sudo sysctl -w vm.vfs_cache_pressure=500

64-bit: I set my money on the nVidia Jetson Orin family. They are, in a sequence from reasonable affordable to absurdly expensive:

1. Jetson Orin Nano 4 GB
2. Jetson Orin Nano 8 GB
3. Jetson Orin NX 8 GB
4. Jetson Orin NX 16 GB
5. Jetson AGX Orin 32 GB
6. Jetson AGX Orin 64 GB

Models 1, 2 and 3 come with a six-core Cortex-A78; Models 4 and 5 make that a eight-core; Model 6 has even a 12-core.

There's no RK3588 board that can shine a light to these specs, period.

[Dirk Broer]

Too bad that Nvidia has fallen into the same trap that SolidRun did some ten years ago, when they copied the form factor of the original Raspberry Pi but instead of the single-core ARM11 that powered the Raspberry gave you the choice of either a single-, dual-, or quad-core Cortex-A9 in their CuBoxes and on their Hummingboards. But you had to pay for the extra performance. The difference was that much that Raspberry became the industry standard while SolidRun still struggles to be alive.

Will Nvidia see thee same fate? I guess not, as they have far more irons in the fire (Dutch saying translated) with their Teslas, GPUs and specialized AI hardware. But I think it is still a crying shame that the old Cortex-A57 4GB Jetson Nano devkit is now being sold for €266.50, while that used to be €99.00! The Jetson Orin Nano starts at €645.00...

So much then for the ARM Cortex-A78 based boards, we'll stick with the Cortex-A76 for the next year(s)! The various Rockchip RK3588 models have four of those A76 cores and add another four A55s, scoring four top-10 marks in Jeff Geerling's Gflops per Watt rankings*. The Cortex-A76 quad-core Raspberry Pi 5 Model B(#19 for 16GB model and #20 for 8GB model), Pi 500 (17) and CM5 Compute module (14) don't do that bad either, especially at the single-core scores.

*=four of the other six consist of hyper expensive multi-core Altera Servers, #1 is the Apple Mac Mini M4 and #2 position is for the M4 Max Mac Studio.

[Dirk Broer]

Either Nvidia reads this forum (unlikely), or their marketing department has at least one genius: they brought out a new, uprated Jetson Orin Nano kit at half the price of the original, for a 'mere' $249 -but you get real power here. see https://jetsonhacks.com/2024/12/17/jets ... loper-kit/

N.B.: There is a project that uses the Nvidia GPU in ARM SBCs: SRBase's TF application already runs now on my Jetson Nanos! So I have to upgrade the OS on my Xavier to be able to run it on that board too.

[Dirk Broer]

The competition doesn't rest on its RK3588 laurels! In case you are still hesitating between buying a RK3588 board (superior performance in raw GFLOPS and GFLOPS/Watt) or a Raspberry Pi 5 (superior hardware and software support) here's a new choice:
the duodeca-core (12-core) Radxa Orion O6, World's First Open Source ARMv9 Motherboard.
Yes, no SBC, but an iTX mobo featuring a Cix CD8180 SoC of Armv9.2 Architecture (so no option anymore to run 32-bit apps) with a 45 TOPS NPU.
Nobody has yet found a real need for NPUs, BOINC-wise, but... that can change. If so, this board has some power -even if it pales a bit against the latest Nvidia GPU/NPUs.

[Dirk Broer]

While Jeff Geerling in February 2025 already seemed less than impressed about the Cix CD8180 equipped Radxa Orion O6 (An ARMv9.2-A SOC featuring four Cortex A720@2600 MHz (big), four Cortex A720@2400 MHz (medium) and four Cortex-A520@1800 MHz (LITTLE)), the performance of its (BOINC-wise unfunctional) NPU has been recalibrated to 28.8 TOPS (the previously mentioned 45 TOPS now seems to be the total for NPU, GPU and CPU together), and the whole ARM community still waits for decent hardware acceleration for the ARM Immortalis-G720 GPU, like any other ARM GPU except for those of Nvidia (and even then it is nowhere near X86/X64 support). His May 2025 re-assessment is not that much more positive. Advice: Wait two years, until ARMv9.2-A has become mainstream.

BTW: There is a Orange Pi 6 plus coming, equipped with the Cix CD8180 too...models with up to 64 GB of RAM have been announced.

Rockchip in the meantime has plans to introduce a RK3688 with even better specs (An ARMv9.3-A SOC featuring four Cortex-A730 high speed cores (big), four Cortex-A730 normal speed cores (medium) and four Cortex-A530 efficiency cores (LITTLE)). Rumours speak about a 32 TOPS (BOINC-wise still unfunctional) RKNN-P3 NPU. The ARM Immortalis-G730(?) GPU should be capable of 2 TFLOPS and the 128-bit RAM can be of LPDDR5 or LPDDR6 variety, offering 200 GB/s bandwidth. This promises to be one pricy f***ker, so there is also a plan for an economy-version:

The RK3668 (An ARMv9.3-A SOC featuring four Cortex-A730 high speed cores (big), and six Cortex-A530 efficiency cores (LITTLE)). This all coupled to a 16 TOPS NPU, an ARM Immortalis-G530(?) GPU of 1-1.5 TFLOPS and LPDDR5/6 RAM with 100 GB/s bandwidth -still better than the present flagship, the RK3588. As my earliest posting about the RK3588 has shown before, also wait two years here (so somewhere in 2027) before it actually comes to the market without major obstructions.

There is a Radxa Rock 6 going around in the rumour-circuit that may be equipped with either of these two Rockchip SOCs...

But, if you're looking for a real-life now functioning ARMv9.2-A SOC with about the same specs: look into the system info of your own smartphone, e.g. the Samsung Galaxy A56 with its Samsung Exynos 1580 CPU. Can't Hardkernel make a Odroid-XU5 with that? Even the older Exynos 1480 or 1380 might do. Yes, the very same SOCs that powered the previous Galaxy A55 and Galaxy A54.

[Dirk Broer]

ARM hardware has come in various generations. The oldest that you can still use with BOINC is ARMv5, and that only with radioactiveathome.
You can find ARMv5tel (ARMv5TE little-endian) devices in older, low-power embedded systems, primarily featuring Marvell Orion/Kirkwood processors, such as e.g. the Sheevaplug, QNAP TS-109/209/409, Linksys NSLU2, and Buffalo Linkstation. These devices, popular in the late 2000s and early 2010s, often served as NAS or DIY servers, though mainstream support has largely ended.

The audience here is probably more familiar with the successor to ARMv5, unsurprisingly called ARMv6. There was ARMv6el (soft float/little endian) and ARMv6hf (hardware floating point, improving performance in BOINC considerably). A well-known example is the Broadcom BCM2835, found in the single-core Raspberry Pi models, such as the original Raspberry Pi Model A and B variants, but also in the Raspberry Pi Model A+, B+, the original Compute module and the Raspberry Pi Zero.

Armv6 was -even more unsurprisingly- followed by the yet more capable ARMv7. A short-lived example of this is the ARM-Cortex-A7 based Broadcom BCM2836, found solely in the first quad-core Raspberry Pi B model 2 (v1.1), because the v1.2 already had the yet more advanced BCM2837, with underlying ARMv8 architecture. But there were more ARMv7 SOCs that lived far longer, such as e.g. the Cortex-A8 in the Sitara AM3358 of the BeagleBone Black, or the Cortex-A5 in the Amlogic S805 of the Odroid C1.
To put things in perspective
Click on the picture to see it in a bigger format.
Now while the various architectures had up to now shown very little differences within, this changed with ARMv8. In fact there are ARMv8.0-A, ARMv8.1-A, ARMv8.2-A, ARMv8.3-A, ARMv8.4-A, ARMv8.5-A, ARMv8.6-A, ARMv8.7-A, ARMv8.8-A and ARMv8.9-A SOCs. There are also ARMv8-M (for microcontrollers) and ARMv8-R (real-time designs) profiles.

Now when the support for ARMv5 is virtually non-existent in BOINC (except for radioactiveathome) and the amount of work that can be done with ARMv6 is dwindling away too, ARMv7-based apps are still alive and kicking. A good example is SiDock@Home, all three applications mention Linux running on ARM, hardware FP. If you want real performance for these apps you need either an ARMv7 based SOC featuring the ARMv7 Cortex-A15 or Cortex-A17, or you can choose to let your ARMv8-based SBCs to run a 32 bit OS. This however is only a valid solution when you solely concentrate on ARMv7-based apps from BOINC projects. If you want an ARMv8-based system to be able to run both ARMv7- and ARMv8-based apps you can do the following:

Code: Select all

sudo dpkg --add-architecture armhf
sudo apt update --fix-missing
sudo apt install libc6:armhf libstdc++6:armhf zlib1g:armhf libfuse2:armhf libgomp1:armhf libboinc7:armhf
sudo apt full-upgrade

and add this to your cc_config.xml in /var/lib/boinc-client (or /var/lib/boinc, depending on your distro and/or distro version)

Code: Select all

<cc_config>
<options>
<alt_platform>arm-unknown-linux-gnueabihf</alt_platform>
<alt_platform>armv7l-unknown-linux-gnueabihf</alt_platform>
</options>
</cc_config>

Now if you also happen to run the BOINC project iThena.Measurements, you might now get errors when running their ARMv7-based CNode-app. Especially when you e.g. live in the Netherlands, run an UK English BOINC and use a US international keyboard (with the Euro on 5). iTHena can't handle that (and other project apps perhaps as well).
How to cure this?
edit /lib/systemd/system/boinc-client.service to include the Environment parameter Environment=LC_ALL=C (as the error points to locales).

Code: Select all

[Unit]
Description=Berkeley Open Infrastructure Network Computing Client
Documentation=man:boinc(1)
After=network-online.target

[Service]
*Added line to test whether inclusion of the Environment parameter helps
Environment=LC_ALL=C
ProtectHome=true
Type=simple
Nice=10
User=boinc
WorkingDirectory=/var/lib/boinc
ExecStart=/usr/bin/boinc
ExecStop=/usr/bin/boinccmd --quit
ExecReload=/usr/bin/boinccmd --read_cc_config
ExecStopPost=/bin/rm -f lockfile
IOSchedulingClass=idle

With these modifications my Rock Pi 4B+ and my Odroid-N2+, both 4GB hexa-core systems managed to have top scores for me. In fact it was the only project where the Rock Pi 4B+ did anything really usefull, both Science and BOINC credits-wise (The Odroid-N2+ was very good in WEP-M+2 too).
But for everyday purposes, my oldest ARMv8 systems (ARMv8.0-A with less than 1GB RAM per core) now seem to be lacking in capabilities.

What to replace them with?
Jetson Nano 2GB Dev Kit -> Jetson Orin Nano 8GB Super Dev Kit (ARMv8.2-A)

• Pros: More cores (6 compared to 4), more performance, More RAM per core (1.5GB compared to 0.5GB), lesser wattage (the Jetson Nano 2GB has been overclocked to 2000 MHz, running at 20 Watts....)
• Cons: The price, the Orin Nano 8GB Super Dev Kit costs at least 309 Euros.

Odroid-N2+ 4GB -> Odroid-M2 16 GB (ARMv8.2-A)

• Pros: More cores (8 compared to 6), more performance, More RAM per core (1 or 2GB compared to 0.67GB)
• Cons: The price, when ordering through Odroid.nl (which is a UK company) the 8GB model costs 159.30 Euros (excluding VAT, handling and postage), the 16GB model costs 212.40 Euros (again excluding VAT, handling and postage). When bought in the Netherlands the 16GB model is €241.94, which might be cheaper in the end.

Rock Pi 4B+ 4GB -> Now here it gets interesting. A new 8GB or 16GB version of the octa-core Radxa Rock Pi 4D would take care of the RAM-based problems, but it would still be an ARMv8.0-A based system, no improvement there. Radxa also happens to have a new Radxa Dragon Q6A SBC, based upon a Qualcomm Dragonwing™ QCS6490, which is ARMv8.4-A* based and the 12GB and 16GB versions of it seem more than adequate for some time to come.

• Dragon pros: More cores (8 compared to 6), more performance, More RAM per core (1, 1.5 or 2GB compared to 0.67GB)
• The price is the selling point for the Dragon: the 8GB model costed 70 Euros until they changed it -during my writing this(!)- to 99 Euros, the 12Gb model 120 Euros and the 16GB model is presently not for sale.

* According to well-known SBC expert Thomas Kaiser the ARMv8.4-A for the Qualcomm QCS6490 Dragonwing is pure marketing (if so, even supported by Wikipedia), and he has some pretty convincing arguments...