I think that ARP1, HSTB, and MIP1 would surely not run on ARM because of the required memory.
At the other side, MCM and SCC1 (when available) would probably run fine.
Cheers,
Yves

Yves (KerSamson) has it right, I think. On Intel/AMD systems, only MCM1 and SCC1 make minimal references to L3 cache (and I mean references, not misses)). I've done lots of throughput monitoring of WCG tasks on Linux systems so this is based on data, not guesswork. All others hit on L3 cache quite a lot; whether that means more misses or not isn't actually that relevant to this matter...

A basic ARM-based system such as a Pi4 doesn't have any L3 cache, so any L2 misses go straight to RAM! (Obviously, write activities will tend to go straight to RAM regardless, but a lot of the L2 misses are probably read activities looking at "database" information.) So any application that seems to reach out to L3 cache a lot will probably have a much higher memory access overhead than an L3-friendly program!

If I run my normal workload of three tasks at once on my Pi4 (at 2GHz!) they tend to take between 6.5 and 7 hours (depending on job complexity); when I had some MCM1 beta tasks on the Pi (with VMethod=LOO, which makes a difference to run-time) they were taking about 4.5 hours. Now, that's significant, because on my other systems OPN1 tasks tend to take about as long as MCM1 tasks with VMethod=LOO!

(And if I only run one task at a time on the Pi4, they take well under 6 hours each, and that is down to there being less memory contention! I didn't get a chance to time a single MCM1 beta task; they'd all run before I even realized I'd had any!)

So it would appear that a Pi4 will make a better fist of running MCM1 (and by implication, SCC1) than any of the other task types. We already know that the likelihood of a rebuild of HST1 is remote (discussed elsewhere in the context of Linux C library issues with vsyscall), FAH2 is effectively finished, ARP1 would probably be a non-starter because of the required memory (even if cache wasn't a problem), and given how quickly MIP1 can make a system with an L3 cache appear memory-bound, I suspect it would effectively induce torpor in a Pi4, so probably not a good idea either.

We've already had MCM1 betas for Linux on ARM, so can hope that if/when that version is let loose we'll get to see the ARM build; let's hope that if/when they Beta test for the next type of SCC1 data they can do a Linux ARM build for that too!

Cheers - Al.

P.S. native-mode ARM applications for Apple M1 are a different matter - that will have to be addressed at some point, and the memory and cache issues shouldn't be so critical there.

[Edited to fix a word-choice...]

Hi all,
I totally agree with the initial post of this thread. Raspi 4 are so power efficient and money saving platforms. I have two of them running 24/7 at home. It's so sad to see only 1 project running...
I really hope they should crunch on more projects in the future.
Regards

Hi Martin,
it is as easy to install boinc on an RPi as on other Linux-based systems.
I recommend to install the original Raspios version on the SD card:

• Version with Desktop Environment
  https://downloads.raspberrypi.org/raspios_arm...-raspios-buster-armhf.zip
  
• Lite version
  https://downloads.raspberrypi.org/raspios_lit...ios-buster-armhf-lite.zip

Currently Raspios is still 32 bit but it does not impact WCG projects negatively even on RPi4.
As soon as Raspios is installed, you shall do following:

• Full Raspios update
  

  sudo apt-get update
  sudo apt-get upgrade
  sudo apt-get update
  sudo apt-get full-upgrade
  sudo reboot

• Firmware update
  

  sudo rpi-update
  sudo reboot

  Repeat #1 followed by #3
  
• Install boinc as usual:
  

  sudo apt-get install boinc

• Followed by the traditional boinc configuration and project attachment and concluded with:
  

  sudo reboot

On my side, I use an ssh session (CLI) for administering the RPi and I use BoincTasks for managing boinc.
If you plan to use directly ssh (headless system), you shall put an empty file named ssh (without extension) in the boot partition prior the first boot:

cd /Volumes/boot
touch ssh

Otherwise it is possible to enable ssh using the configuration tool from the system console:

sudo raspi-config

Recommendation

• Per default the swapfile (swap space) is 100 MB large. On a RPI3, it is too small if you plan to crunch more than 2 WUs simultaneously. I would recommend you to increase the swapfile size from 100 MB to, at least, 256 MB.
  
• You can as well install RPi-Monitor on the RPi for remotely monitoring the RPi's health (see below). It is a web-based application allowing you to see CPU temperature, CPU load, memory usage, ...

RPi-Monitor installation

• Install RPi-Monitor‘s public key to trust RPi-Monitor repository:

  sudo apt-get install dirmngr
  sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 2C0D3C0F

  
  
• Execute the following command to add RPi-Monitor into your list of repository:
  

  sudo wget http://goo.gl/vewCLL -O /etc/apt/sources.list.d/rpimonitor.list

  
  
• To install RPi-Monitor, execute the following command:

  
  sudo apt-get update
  sudo apt-get install rpimonitor

You can reach RPi-Monitor over port 8888:

http://hostname:8888

• After the installation of RPi-Monitor, you shall execute:

  sudo /etc/init.d/rpimonitor update to update this data.

• And you can add or remove automatic update of this data, execute

  sudo /etc/init.d/rpimonitor install_auto_package_status_update

  or
  

  sudo /etc/init.d/rpimonitor remove_auto_package_status_update

Hopefully my explanation is sufficiently clear if not, feel free to ask again (Fragen kostet nichts ).
Good luck,
Yves