My ARM fleet

[Dirk Broer]

PrimeGrid is supposed to have Linux ARM64 applications for GFN16 and GFN17 but I cannot get them to get work on my Odroid.

Only works for Asteroids and SiDock (and the NCI WuProp).

Do you get work, but do they error out (if so: what error messages?), or do the WUs just not come at all?

P.S.: It doesn't look all that bad, one of your Odroid-N2 has done a GFN-16 and is busy with another GFN-18.

[vaughan]

Yes Dirk, it is working now. Rytis worked it out for me, I had initially set the venue to "home" and I had thought that Odroid was set for "neptune". When I logged into my computers under my account I changed it from venue home to venue neptune and it immediately got work. I adjusted the subprojects to GFN16, 17 and 18 only. After the applications developer Yves wrote on Discord I changed it to GFN only and set 6 thread down to 4 threads as I didn't realise Ordoids have 4 powerful and 2 economy cores.

Task this weekend is to get the other Odroids (15 in total, I think) running again. They haven't been attended to in years as they were on set and forget WEP-M+2.

[Dirk Broer]

With both WEP-M+2 and Universe@Home down and/or out the fleet has turned its attention to SiDock@Home.
SiDock is far tougher though on the SBCs than WEP-M+2 or Universe@Home. Like Universe@Home it has presently only 32-bit work, but it has more needed requisites.
The Odroid-C1, Hummingboard-i4ex and both Raspberry Pi 3Bs bit the dust on SiDock and are waiting for the revival of Universe@Home.
My Jetson Nano 2GB gets no work done on account of its L4T Linux version is too old (nVidia standard adaption of Ubuntu 18.04.6 LTS with kernel 4.9.201) and only has GLIBC 2.27, while 2.28 or higher is needed.
My Jetson Nano 4GB gets no work done on account of missing libgomp1:armhf and my Jetson Xavier NX and my Raspberry Pi CM4 ran out of diskspace with SiDock.
The rest off the fleet does well though, it is not the debacle that I faced trying to run the 64-bit Asteroids@Home application on all cores of the SBCs.

At the moment I am one of the few participants worldwide (#4 out of 91) to get any work it seems, as I pointed all my capable ARM-SBCs to this project.
And though the application itself is a 32-bit piece of code, it needs a beefy* 64-bit board to crunch it in a reasonable amount of time.
This doesn't go all by itself though, it needs

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

to be able to run 32-bit code.

Additionally you have to add at least the upper alternate platform identifier to your cc_config.xml file when running on a 64-bit ARM platform:

    <options>
        <alt_platform>arm-unknown-linux-gnueabihf</alt_platform>
        <alt_platform>armv7l-unknown-linux-gnueabihf</alt_platform> *was needed in the past for WCG*
        <alt_platform>armv6l-unknown-linux-gnueabihf</alt_platform> *was needed in the past for other projects*
    </options>

* beefy as in 'a Raspberry Pi 3 Model B+ (1400MHz Cortex-A53 with 1GB of RAM) won't cut it, an Odroid-M1 (1992 MHz Cortex-A55 with 8GB of RAM) gets but slowly through it'.
Raspberry Pi 4's do go through them though, as does (surprisingly) my hexa-core Rock Pi 4B+.
My Odroid-N2+ needed (a larger) ZRAM allocation, my Jetson Nano 2GB needed Ubuntu 20.04@1900 MHz (definitely not standard), while my Jetson Nano 4 GB (Ubuntu 20.04@1400MHz) has just a tad more speed than the Odroid-M1.
The Raspberry Pi 5 flies through them.