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.