Hello,
I am a new E@H participant, dedicating 2 Raspberry Pi’s to the BRP4 search. I am currently seeing a high invalid task count on my new Pi 4 that I do not see on my older Pi 3.
Pi 3 information:
OS – Raspbian Jessie (Linux 4.9.35-v7+) that is up to date
BOINC – Debian version 7.4.23+dfsg-1+deb8u1
E@H Client – E@H version 1.47 (NEON)
This computer has been running E@H the longest with no problems and no invalid tasks at this time.
Pi 4 information:
OS – Raspbian Buster (4.19.58-v7l+|libc 2.28 [Debian GLIBC 2.28-10+rpi1]) that is up to date
BOINC – Debian version 7.14.2+dfsg-3
E@H Client – Debian boinc-app-eah-brp version 0.20170426+dfsg-2+b7
This computer has been running for just a few days. After some problems getting the correct E@H client it is running and completing tasks with no problems. The problem that I am seeing is a high invalid task count of about 10% so far. Reading the FAQ an invalid task count of about 1% is expected. I have searched these forums for any information on this but have not found any.
I would like to know if this high invalid count is due to my setup, and if it is how I can correct it. Any information or help with this would be greatly appreciated.
Tom
Copyright © 2024 Einstein@Home. All rights reserved.
Thomas Weyhrauch
)
Try this thread:
[url]https://einsteinathome.org/content/parallella-raspberry-pi-fpga-all-stuff[/url]
Thomas Weyhrauch wrote:Pi 4
)
Get rid of the boinc-app-eah and use the 1.47 beta app. I had all sorts of trouble with the optimised apps on the Pi3’s.
You might want to update the Pi3 to Buster while you’re at it. They don’t even do security fixes for Jessie any more. I’ve updated all of mine, well I clean installed them.
MarksRpiCluster
mikey wrote: Try this
)
Hi Mikey,
I am now reading that thread from the start. I had previously read parts of it on my search for more information.
Thanks, Tom
PorkyPies wrote:Thomas
)
Hello PorkyPies,
When I installed BOINC on my Pi 4 I did not install the Debian BRP4 client. When I added E@H to BOINC I got 42 tasks that errored out instantly. I checked the E@H applications and both (1.46 and 1.47) were for ARMv6 and the Pi 4 is ARMv7. I then found the Debian BRP4 client in add/remove software and installed it. After that BOINC got tasks normally and completed them with no problems. After a couple of days I noticed the high invalid count and I started looking for answers.
I did not try the version 1.47 app because I thought it would act the same as the 1.46 app. Is that an incorrect assumption? Are you saying that the 1.47 runs with no problems on the Pi 4?
Best Regards, Tom
The 1.46 app is indeed able
)
The 1.46 app is able to work on ARMv6 - until Debian Stretch came along (2 years ago) and broke it.
The 1.47 app uses neon extensions that ARMv7 and upwards have. It will work on the Pi2 and later.
I don’t have any Pi4’s yet so haven’t tested the 1.47 app on it but it should work. My Pi4’s are on back order.
MarksRpiCluster
I know this is an old thread,
)
I know this is an old thread, but I am facing a very similar issue. My RPi3 was running Ubuntu 32 bit on had no issue running- Application:Binary Radio Pulsar Search (Arecibo) v1.47 (NEON) arm-unknown-linux-gnueabihf
But the problems started with I purchase a new RPi4 and loaded Buster on to both devices
Old RPi3 (Ubuntu, running fine): https://einsteinathome.org/host/12822443
New RPi3 (Buster, all errors): https://einsteinathome.org/host/12835097
New RPi4 (Buster, all errors): https://einsteinathome.org/host/12835006
New OS: Linux Raspbian Raspbian GNU/Linux 10 (buster) [5.4.42-v8+|libc 2.28 (Debian GLIBC 2.28-10+rpi1)] (I have the 64 bit flag enabled)
Here is an example of the error-
</stderr_txt>
]]>
As you can see all WUs are erroring out and BOINC is attempting to run Application:Binary Radio Pulsar Search (Arecibo) v1.06 on the devices. arm-unknown-linux-gnueabihf
Why is the v1.06 app running on the device and not v1.47? - I have the beta flag / test apps flag set to yes.
Do I need to resort to using the anonymous app in the program catalog? Debian boinc-app-eah-brp
Any help would be greatly appreciated.
DavidH wrote:Here is an
)
Boinc error code wikipage says error code #127 means:
ERR_UPLOAD_TRANSIENT -127
First an explanation what transient means. Transient refers to a module that, once loaded into main memory, is expected to remain in memory for a short time.
This is a server error. The file you are trying to upload is locked on the server. The file_upload_handler put an advisory lock on the file, to prevent other file upload handlers to write to the file.
This can only be fixed by the project.
Extra messages in 5.8 branch of BOINC.
[url]https://boinc.mundayweb.com/wiki/index.php?title=Error_code_-121_to_-130_explained[/url]
But I'm not sure what you posted and what it says are the same thing, so maybe that's a no longer valid page, it is fairly old.
Try this page here on Einstein too:
[url]https://einsteinathome.org/content/what-exit-status-127[/url]
All, Following up on this
)
All,
Following up on this thread. I was unable to get my RPi to download the v1.47 apps, so I am using the anonymous app found in the program catalog: Debian boinc-app-eah-brp
That has been working over the past few days without issue.
thank you MIKEY for the links, they were helpful.
DavidH
)
You are very welcome, I'm glad it's working now!!
If you’ve put the Pi into 64
)
If you’ve put the Pi into 64 bit mode then it’s aarch64 architecture. Einstein doesn’t have an aarch64 app which is why it gives the v1.06 app. Unfortunately v1.06 hasn’t worked for years.
I ended up grabbing the v1.47 app off another Pi and creating an app_info.xml to run it. Raspbian can run the armhf apps as well as aarch64 apps. I haven’t tried the experimental Raspberry Pi OS (64 bit) yet.
There is no real advantage to running 64 bit just for Einstein. If like me you are running other projects that do have aarch64 apps then you could do what I did. Hopefully the project will get aarch64 apps in the future.
If you want your Pi to download the v1.47 app you have to put it back into 32 bit mode (armhf) reset the project and then allow new tasks. If you don’t need 64 bit it would be best to leave it in armhf mode.
MarksRpiCluster