What kind of Powersupply do you use? Running the PI with for BRP-tasks(or other computation-intensive) results in a fast and high current-delta between min & max -> https://einsteinathome.org/de/goto/comment/149830.
The Powersupply must be able to regulate that. If the Powersupply can't handle this, the voltage drops. There are not really capacitors on the PI to compensate this.
By looking at your tasks with "Computation Error", I could see different errors. Segmentation-Faults and Illegal-Instruction-errors.
Maybe only the Powersupply is faulty or not good enough.
Hi Christian, your English is fine; much better than my German.
I have used various power supplies. Originally, I had it hooked up to a 5-port 40W 8A USB charging hub with two other Pis (so, 3 Pis total on the hub). After the first series of crashes, I moved it to it's own 5V 2.5A power adapter. Since I still got similar crashes, I assumed it wasn't a power issue. Also, neither of the other two Pis have had any crashes or errors and they have only been running attached to the USB charging hub.
Since my last (previous) post, I have run additional stress tests (30 minutes of stress) and memory tests (10 loops of memtester) and the Pi has "passed" with no memory errors noted, no throttling and temps remaining below 65 degrees -- and no crashes.
It's puzzling. The hardware appears to be okay. It just crashes when I run boinc-client (with or without the optimized app). The other two Pis run just fine.
I've swapped out parts in terms of trying different micro SDcards and USB thumb drives (that are identical to those in the two working Pis). I haven't swapped the actual cards/thumb drives from the two working Pis, and for a number of reasons I probably won't.
I've actually retired rpi3-3 from BOINC now that all of its remaining tasks have been completed (unfortunately, all of which resulted in errors). I've already got it doing some other stuff and it has been working just fine (prior to BOINC, it was a Jupyter server and it has been returned to that duty). For now, its issues with BOINC will just have to remain a mystery, I guess. The other two Pis are chugging along problem-free and, as the song goes, two out of three ain't bad.
So I finally got around to using this on my 3 Raspberry Pi 3s and I'm seeing very satisfactory speed improvements. One machine has the In-Place version and the others have the Out-of-Place version. Running 3 concurrent tasks I'm seeing much better performance on the device with the IP version, which I'll attribute to memory constraints. On one of the two machine with the OP version I want to switch to the IP version. After letting all the outstanding work complete and stopping the boinc-client, can I just delete the app_info.xml and the executable, download the IP tarball and extract the files?
On one of the two machine with the OP version I want to switch to the IP version. After letting all the outstanding work complete and stopping the boinc-client, can I just delete the app_info.xml and the executable, download the IP tarball and extract the files?
Just to be safe I would set Boinc to "No new task" for Einstein@home and set a low work cache before shutting down. Then after replacement of both the app_info.xml and the executables I would start Boinc and then check the "Event log" for anything out of the ordinary. If all looks good allow new task to download. If things don't crash and burn then reset cache settings and start gathering results for a statistical comparison of the run times before and after the change.
... can I just delete the app_info.xml and the executable, download the IP tarball and extract the files?
Just be aware that specific contents of an app_info.xml file do get inserted into the state file (client_state.xml). Just deleting app_info.xml doesn't actually remove those insertions. At least, that was a previous problem and it may well have been rectified in more recent versions of BOINC, but I would guess not. Rather than take a chance about that and rather than manually editing the state file to remove the insertions, the easiest way to ensure a 'clean' configuration is just to use the 'project reset' option before you download and extract the new tarball.
Just do the other things Holmis recommended and as a last step before shutting down, reset the project. This removes all the previous stuff and gives you a nice clean state file, ready for the next setup.
How would you build this from source and install to run? It is now possible to run 64 bit Debian on a raspberry pi but Einsteinathome will not recognize the os .
How would you build this from source and install to run? It is now possible to run 64 bit Debian on a raspberry pi but Einsteinathome will not recognize the os .
The source code and information was documented in the past. I tried to build the code a couple months ago, but I did not finish. The links point to a source tree that has been moved and the instructions on how to build it have changed. If you are lucky enough to succeed, it would be nice to publish current instructions.
If you download the archives in the OP, you should be able to crunch under 64bit Debian as well. These also work under 64Bit Ubuntu on Odroid C2, both use ARM A53 cores, the app_info.xml makes it ask for work wherever you put it. Give those a try, I'm quite sure it should work...
What kind of Powersupply do
)
What kind of Powersupply do you use? Running the PI with for BRP-tasks(or other computation-intensive) results in a fast and high current-delta between min & max -> https://einsteinathome.org/de/goto/comment/149830.
The Powersupply must be able to regulate that. If the Powersupply can't handle this, the voltage drops. There are not really capacitors on the PI to compensate this.
By looking at your tasks with "Computation Error", I could see different errors. Segmentation-Faults and Illegal-Instruction-errors.
Maybe only the Powersupply is faulty or not good enough.
Sry for my bad english.
Cheers Christian
Hi Christian, your English is
)
Hi Christian, your English is fine; much better than my German.
I have used various power supplies. Originally, I had it hooked up to a 5-port 40W 8A USB charging hub with two other Pis (so, 3 Pis total on the hub). After the first series of crashes, I moved it to it's own 5V 2.5A power adapter. Since I still got similar crashes, I assumed it wasn't a power issue. Also, neither of the other two Pis have had any crashes or errors and they have only been running attached to the USB charging hub.
Since my last (previous) post, I have run additional stress tests (30 minutes of stress) and memory tests (10 loops of memtester) and the Pi has "passed" with no memory errors noted, no throttling and temps remaining below 65 degrees -- and no crashes.
It's puzzling. The hardware appears to be okay. It just crashes when I run boinc-client (with or without the optimized app). The other two Pis run just fine.
Swap parts between your PIs?
)
Swap parts between your PIs?
I've swapped out parts in
)
I've swapped out parts in terms of trying different micro SDcards and USB thumb drives (that are identical to those in the two working Pis). I haven't swapped the actual cards/thumb drives from the two working Pis, and for a number of reasons I probably won't.
I've actually retired rpi3-3 from BOINC now that all of its remaining tasks have been completed (unfortunately, all of which resulted in errors). I've already got it doing some other stuff and it has been working just fine (prior to BOINC, it was a Jupyter server and it has been returned to that duty). For now, its issues with BOINC will just have to remain a mystery, I guess. The other two Pis are chugging along problem-free and, as the song goes, two out of three ain't bad.
So I finally got around to
)
So I finally got around to using this on my 3 Raspberry Pi 3s and I'm seeing very satisfactory speed improvements. One machine has the In-Place version and the others have the Out-of-Place version. Running 3 concurrent tasks I'm seeing much better performance on the device with the IP version, which I'll attribute to memory constraints. On one of the two machine with the OP version I want to switch to the IP version. After letting all the outstanding work complete and stopping the boinc-client, can I just delete the app_info.xml and the executable, download the IP tarball and extract the files?
Regards,
DadX
DadX wrote:On one of the two
)
Just to be safe I would set Boinc to "No new task" for Einstein@home and set a low work cache before shutting down. Then after replacement of both the app_info.xml and the executables I would start Boinc and then check the "Event log" for anything out of the ordinary. If all looks good allow new task to download. If things don't crash and burn then reset cache settings and start gathering results for a statistical comparison of the run times before and after the change.
DadX wrote:... can I just
)
Just be aware that specific contents of an app_info.xml file do get inserted into the state file (client_state.xml). Just deleting app_info.xml doesn't actually remove those insertions. At least, that was a previous problem and it may well have been rectified in more recent versions of BOINC, but I would guess not. Rather than take a chance about that and rather than manually editing the state file to remove the insertions, the easiest way to ensure a 'clean' configuration is just to use the 'project reset' option before you download and extract the new tarball.
Just do the other things Holmis recommended and as a last step before shutting down, reset the project. This removes all the previous stuff and gives you a nice clean state file, ready for the next setup.
Cheers,
Gary.
How would you build this from
)
How would you build this from source and install to run? It is now possible to run 64 bit Debian on a raspberry pi but Einsteinathome will not recognize the os .
bowguy wrote:How would you
)
The source code and information was documented in the past. I tried to build the code a couple months ago, but I did not finish. The links point to a source tree that has been moved and the instructions on how to build it have changed. If you are lucky enough to succeed, it would be nice to publish current instructions.
https://einsteinathome.org/application-source-code-and-license
If you download the archives
)
If you download the archives in the OP, you should be able to crunch under 64bit Debian as well. These also work under 64Bit Ubuntu on Odroid C2, both use ARM A53 cores, the app_info.xml makes it ask for work wherever you put it. Give those a try, I'm quite sure it should work...