I was suspicious about your runtimes and it turns out that for some reason, the latest linux arm app doesn't contain the latest optimizations, I let Georgi know. Feel free to use the older version which should be faster.
https://asteroidsathome.net/boinc/download/period_search_10220_aarch64-unknown-linux-gnu

Yes, on Pi5, the older 10220 version app is 2X as fast as the latest 10221 app. Reverting now.
https://asteroidsathome.net/boinc/results.php?hostid=776701&offset=0&show_names=0&state=2&appid=
[Edit[ Same for the Pi4

---

A proud member of the OFA (Old Farts Association)

Thank you both for your help. I am now crunching the 102.20 app and the runtimes are around 2 hours, an hour less than with aarch64_armv8-a_asimd.

OK, the testing is done. Again, thank you Keith and ahorek's team for your input.

The result is that for Asteroids@Home, there is basically no difference if the Raspberry Pi 5 is using an SD card or an NVMe drive. For Einstein is a totally different story.

Full blog post with the benchmarks: https://stfn.pl/blog/50-pi5-nvme-performance-in-boinc/

Thanks for the comparison numbers for using faster M.2 storage on Einstein and Asteroids applications for the Pi4 and Pi5.

---

A proud member of the OFA (Old Farts Association)

nice, but 33% improvement? something has to be wrong. CPU-heavy tasks should barely touch the file storage.

I used sudo iotop -aoP to monitor the app and observed minimal file access, limited mainly to writing checkpoints. These few kilobytes shouldn't affect performance, even on slow storage like an SD card.

Could swapping be a possible reason? Einstein's tasks are heavier, but ~200MB/tasks should easily fit into 4GB+ RAM. Any other explanation?

I have no idea. I've been monitoring the resources usage, and there was no swapping for sure. With Keith and Ian's help I am now testing a different app in E@H, and we will see how it goes.

And as I mentioned in the blog posts, there is a significant difference in the thermals between Asteroids and Einstein, suggesting that Einstein is underutilizing the CPU on the Pi, so I think the bottleneck is somewhere else.

Universe@Home wasn't loading any work on the arm64 architecture despite of the compatibility shown on the BOINC project list. And Einstein@Home is using a lot of RAM memory (~200 MiB per task), which is too much to run on 4 cores when using 1GB RAM devices without having catastrophic crashes all the times (Linux kernels having become completely unable to keep running fine when something uses too much RAM... for a bunch of years already. Seems it's never going to be repaired)

The dreaded OOM (out-of-memory) killer, which decides (often wrongly) what to kill when RAM+swap run out. One thing that I found very useful on 1 GB devices is, paradoxically enough, to reserve some of that RAM as compressed swap space (zswap). That worked nicely for having 4x Open Pandemics tasks running on Pi 3s without them stomping on one another. The article below is a good place to start, and I've used the script mentioned in the article to set it up.

https://linuxblog.io/raspberry-pi-performance-add-zram-kernel-parameters/

Meanwhile, I've just joined a small fleet of RPis (3xRPi5, 2xRPI400, 1xRPI4), and it was humming along nicely until the tasks ran out. Looks like this is a general problem, as my x86 crunchers are also rapidly running out of tasks.