Actual time vs processing vs cpu on RPI
26 Nov 2020 22:04:34 UTC
Topic 224074
(moderation:
Running raspberry pi 3 1gb and have four tasks processing. 32bit command line rpi os.
They've been running the same tasks for 14+ hours now but processing and cpu time in BoincTasks show 8 hours.
No overheating issues or throttling. Can't see any other reasons so thought id post to see if anyone has ideas.
(I know 64bit and BRP4 app is better but it freaks put forn me so not using until can resolve...).
@Sam Here a couple of
)
@Sam
Here a couple of easy-to-check ideas... Your R-Pi has 4 cores so, in principle, it can run 4 tasks concurrently BUT there are "config" file settings that might restrain it. In the cc_config.xml file (base directory for Boinc projects) there is a parameter setting for <ncpus>. It should be 4. In the ../projects/einstein.phys.uwm.edu directory there may be an app_config.xml file with a parameter setting for <project_max_concurrent>. That, also, should be at least 4; and if there are <app> sections in that file (app_config.xml) each <app> section may have a parameter setting for <max_concurrent>, which should be 4. I am running multiple concurrent CPU tasks (O2MD1) on a Ryzen 1700 and they are using 560 to 650 MB RAM each. It's a different app, I realize, Ryzen 64-bit vs. R-Pi 32-bit but it's possible you're short of RAM and swapping heavily. I assume your R-Pi is a Linux OS - bring up the "top" display and see how many tasks are actually running, and how much RAM is in use. If any of these constraints are active then the accumulated run-time for the tasks will be much less than wall-clock time.
Eugene Stemple
)
It should not be specified at all. By default it will use all cores. It’s only present if someone has edited the cc_config. If you want to limit how many it uses then set the % of processors in BOINC Manager.
The app_config is only created if someone has done it manually. It’s not normally present and BOINC won’t create one.
MarksRpiCluster
Sam Osborne wrote:Running
)
The armhf project supplied 1.47 app takes around 14 hours on a Pi3 or 3+ and uses about 133Mb of memory each. The optimised app can do them in 4.33 hours but due to using more memory can only run 3 at a time, however it more than makes up for the loss of a core.
As suggested login to the Pi via a desktop if it has a keyboard and monitor and start a terminal session or ssh into it. Run top. It should show 4 tasks at the top of the running tasks list using 100% of so each. Hopefully they are Einstein tasks. It should also show if it’s using swap and how much free memory it’s got. By default the Pi only has a 100Mb swap. Press Q to get out of top.
If you’ve installed a minimal (aka lite) version of Raspbian it should have no problem fitting 4 into the available memory. Did you set the GPU memory to 16 via raspi-config? That will also free up some much needed memory.
MarksRpiCluster
Hi both, thanks for
)
Hi both, thanks for feedback.
Using top: Four Einstein tasks - 14.5% total memeory (~140mb) each so plenty of space.
100mb swap
I did not set gpu mem to 16 as didnt see an issue with RAM so took a "don't fix if it aight broke" approach.
I normally run Universe@home which runs better on 32bit as of writing (~8 hours per WU) but it's ran dry and Asteriods@home server has gone down due to hardware fault. Wanted to give Einstein a go without re-installing OS and thought these were odd obervations.
Initially it estiamted 3 hours to complete, after 6 hours that had bumped to 10 hours and it took around 15 to complete a WU in the end so around about what @porkypies stated.
When I install 64bit the wifi is super unstable but works find under 32bit. I think this has something to do with removing x11 GUI to free up RAM BUT I cannot confirm. Either way, I don't and cannot run ethernet to where the PI's are located so for now I'll have to run slowboat...
Sam
Sam Osborne wrote: Initially
)
The initial estimates are always way off. Once it’s completed a few tasks it will have a better idea of how long they take.
From memory Asteroids tasks took 23 hours on a Pi4, so assume 48 for a Pi3. Their app has been compiled with ARMv6 CPU in mind and doesn’t use the neon capabilities the Pi2 and later have. It also crashes on the Pi zero or Pi1 which have an ARMv6 so not sure what they did when compiling their app.
MarksRpiCluster
So I shut down one of the
)
So I shut down one of the PI3's and installed 64bit RPI OS. USed https://einsteinathome.org/content/high-speed-linux-brp-app-odroid-c2 guide and it's computation error hell.
Here is the device and the errors - those from 28th Nov.
https://einsteinathome.org/host/12859157/tasks/6/0
I have no idea what the output of these means so any baby step guidelines are welcome.
The person who runs universe@home is hospitalised with covid at present so may be on einstein for a while as he rests up and gets better.
Sam
The server admin is back from
)
The server admin is back from hospital at Universe. He ran the work generator and Universe has work again.
Yah I seen thanks. Still
)
Yah I seen thanks. Still trying to get einstein up but completely baffled. I'm going to fresh install and connect einstein first then download optimised version...
You probably unpacked the
)
You probably unpacked the archive before attaching BOINC to Einstein. Do the following from an ssh or terminal session.
1. Stop BOINC- sudo systemctl stop boinc-client
2. Change ownership of the boinc folder to user BOINC - chown boinc:boinc /var/lib/boinc-client/*-R
3. Restart BOINC- sudo systemctl start boinc-client
4. Allow Einstein to fetch work.
5. Due to the Pi3 only having 1Gb of memory you can only run 3 tasks at a time. Technically they’ll run but will swap a lot so they take almost as long as the armhf app. The optimised app uses more memory per task than the project supplied app. I would reduce the GPU memory to 16 (the minimum) via raspi-config. To limit Einstein to 3 tasks at a time create an app_config.xml file with a project_max_concurrent of 3 and restart BOINC to pick it up.
MarksRpiCluster
Anoyingly I did the above but
)
Anoyingly I did the above but restarted rather than stop - this likely meant it still didnt change ownership of the folder.
Will give it a go thanks