ARM64 Linux / aarch64 apps
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4312
Credit: 250355345
RAC: 35895
10 Aug 2021 16:06:46 UTC
Topic 225817
(moderation:
We recently built an ARM64 app for Linux on a Debian 10 (Buster) machine. It turns out that this produces a lot of errors, as the libc in that is too new and can be found on the machines you intend to run it on.
Can you give us a hint on which OS/Distro/Version you intend to run it, so we can compile it for maximum compatibility?
Thanks,
BM
Linux ubuntu 5.4.0-1041-raspi
)
Linux ubuntu 5.4.0-1041-raspi #45-Ubuntu SMP PREEMPT Thu Jul 15 01:17:56 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
Linux Ubuntu Ubuntu 20.04.2 LTS [5.4.0-1041-raspi|libc 2.31 (Ubuntu GLIBC 2.31-0ubuntu9.2)]
ARM BCM2835 [Impl 0x41
)
BCM2835 [Impl 0x41 Arch 8 Variant 0x0 Part 0xd08 Rev 3]
(4 processors)
Raspbian GNU/Linux 10 (buster) [5.4.83-v8+|libc 2.28 (Debian GLIBC 2.28-10+rpi1)]
and
ARMv7 Processor rev 3 (v7l) [Impl 0x41 Arch 7 Variant 0x0 Part 0xd08 Rev 3]
(4 processors)
Raspbian GNU/Linux 10 (buster) [5.4.83-v7l+|libc 2.28 (Debian GLIBC 2.28-10+rpi1)]
they are offline at the moment though so testing isn't possible right now
Linux Ubuntu Ubuntu 18.04.5
)
Linux Ubuntu
Ubuntu 18.04.5 LTS [4.4.179|libc 2.27 (Ubuntu GLIBC 2.27-3ubuntu1.4)]
Linux Ubuntu
Ubuntu 20.04.2 LTS [4.9.241-114|libc 2.31 (Ubuntu GLIBC 2.31-0ubuntu9.2)]
Linux Raspbian
Raspbian GNU/Linux 10 (buster) [5.10.11-v7+|libc 2.28 (Debian GLIBC 2.28-10+rpi1)]
Linux Debian
Debian GNU/Linux 10 (buster) [3.10.37|libc 2.28 (Debian GLIBC 2.28-10)]
CPU type: ARM Hardkernel
)
CPU type: ARM Hardkernel ODROID-C4 [Impl 0x41 Arch 8 Variant 0x1 Part 0xd05 Rev 0]
Operating system: Linux Ubuntu Ubuntu 20.04.1 LTS [4.9.218-25|libc 2.31 (Ubuntu GLIBC 2.31-0ubuntu9)]
Linux odroidc4 4.9.218-25 #1 SMP PREEMPT Mon Jun 8 13:54:52 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
CPU type: ARM ARMv8 Processor rev 1 (v8l) [Impl 0x41 Arch 8 Variant 0x1 Part 0xd07 Rev 1]
Coprocessors: NVIDIA NVIDIA Tegra X1 (3964MB)
Operating system: Linux Ubuntu Ubuntu 18.04.5 LTS [4.9.201-tegra|libc 2.27 (Ubuntu GLIBC 2.27-3ubuntu1.4)]
Linux Jetson 4.9.201-tegra #1 SMP PREEMPT Fri Feb 19 08:40:32 PST 2021 aarch64 aarch64 aarch64 GNU/Linux
Just seeing this, added the above, seem to be running OK.
I've been giving this a try
)
I've been giving this a try on my collection of arm devices.
Raspberry Pi Cluster:- Linux Debian Debian GNU/Linux 10 (buster) [5.10.52-v8+|libc 2.28 (Debian GLIBC 2.28-10)]
Jetson Xavier nx :- Linux Ubuntu Ubuntu 18.04.5 LTS [4.9.253-tegra|libc 2.27 (Ubuntu GLIBC 2.27-3ubuntu1.4)]
Jetson Nano :- Linux Ubuntu Ubuntu 18.04.5 LTS [4.9.253-tegra|libc 2.27 (Ubuntu GLIBC 2.27-3ubuntu1.4)]
On the cluster of twelve raspberry pi's (Craypi 1-12 overclocked between 1900 and 2000, mix of 4gb & 8gb models) runtime with 3 (of 4) cores running its about 22 hours (per task), but with all 4 cores running (on the 8gb models in the cluster) run time is about 26 hours (per task).
Seeing as my old i7-4790 CPU takes about 12 hours (per task) I didn't think that was too bad. The only surprise to me was the slowdown when running it on all cores (on 8gb pi's) I don't normally see this drop off in runtime on other Boinc tasks (Rosetta, LHC, WCG). My guess is that its a pi memory bandwidth issue.
Also another odd thing is the clusters power usage, when running Rosetta/WCG its using about 88 watts and when running LHC (sixtrack) its about 118 watts (boy that does max out the pi's and cause me cooling issues sometimes) but running Einstein the cluster is using 70 Watts. I know due to memory constraint all the cores are not being used (only 40 out of 48) but I sometimes get that when running Rosetta.
The Nano takes about 24 hours, which is pretty good for an old A57. Normally the Nano gets nowhere near the pi's speed when running Boinc tasks (its normally dead slow).
But the biggest surprise of all is the Xavier nx, each task is taking around 9 hours (with 5 cores out of 6 running), while not as fast as my m1 mac (around 2.5 hours per task), its amazing for an arm core clocked at 1.4GHz. I can only assume that both the Nano and Xavier are using a bit of Nvidia SOC magic, or its because this task needs to have a good memory bandwidth, which these both have (and the Pi's don't).
It looks like the current App
)
Thanks.
It looks like the current App v. 1.16 built on Ubuntu 18.04 should satisfy all needs.
BM
Hi, I intend to run it in
)
Hi,
I intend to run it in a raspberry pi with 64 bits Raspberry OS (bullseye based). The libc version is 2.31-13+rpt2+rpi1+deb11u4 and kernel 5.15.61.
I changed manually the architecture to "aarch64-unknown-linux-gnu" and i get a lot of invalid results that didn't happen in 32 bits (60 valid, 15 invalid is the usual). ¿Is there any other option to improve the situation?
I'm running a Pi4 on the same
)
I'm running a Pi4 on the same kernel on Bullseye and I am not seeing that high an invalid rate.
The ARM apps have a harder time in validation against all the other types of PC hardware generally.
Host 12932108
Check your cooling and clocks.
Yep, it was hitting
)
Yep, it was hitting constantly undervoltage issues. I reducede the voltage a little bit, still at 1.6 Ghz and it looks stable now. In a few days indeed it looks like the invalid situation has improved (87 valid and 15 invalid) so it might just be it (temps are in the 70 - 72º C so no issues here). Thanks!
Keith Myers wrote: The ARM
)
The aarch64 apps seem to have harder time in validation against other ARM hardware too (while eventually validating pretty well against Intel GPUs, not sure about that however).
.