Raspberry Pi Debian Stretch E@H

JamieOnUbuntu
JamieOnUbuntu
Joined: 4 Oct 15
Posts: 11
Credit: 1542971
RAC: 0
Topic 210238

Hi,

I recently reinstalled the OS on my Pi 2B to upgrade to Raspbian Stretch, however I am now unable to get E@H to run any tasks.

I'm aware that there are some issues with libc, where BOINC only runs with older versions (the versions used on Wheezy and Jessie).

Reading the forums, it seems that enabling test/beta apps in your E@H web preferences is the solution, however I am having no luck.

I have not received any new tasks since changing this setting since I have 40 existing tasks that are incompatible and unable to start.

Do I need to wait for these tasks to expire before new ones will be requested? I am unable to manually abort them from boinccmd since they were never actually downloaded. I can only see them from the web interface.

Any suggestions would be much appreciated.

Thank you.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109383146151
RAC: 35952845

It helps in the understanding

It helps in the understanding of the problem if you put everything in the one place :-).

Why don't you just issue a project 'reset'?  That should clean everything out and allow you to start afresh on that particular host.

 

Cheers,
Gary.

JamieOnUbuntu
JamieOnUbuntu
Joined: 4 Oct 15
Posts: 11
Credit: 1542971
RAC: 0

Thanks for your reply!   My

Thanks for your reply!

 

My apologies for having two posts :)

 

 

 

I checked the scheduler logs and it seems that you were right! I have exceeded my daily limit:

2017-10-16 20:07:59.8834 [PID=3821 ] [send] stopping work search - daily quota exceeded (13>=4)

Is the daily limit per-host or per-account?

 

The task error that I am getting is:

../../projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON: relocation error: ../../projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON: symbol h_errno, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

This seems to be a known issue on Debian Stretch since it uses a newer version of libc. Enabling "Run Test Applications" from the web interface is the solution by the looks of it.

 

I'll let you know how it goes, thanks for your help!

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109383146151
RAC: 35952845

JamieOnUbuntu wrote:I checked

JamieOnUbuntu wrote:

I checked the scheduler logs and it seems that you were right! I have exceeded my daily limit:

2017-10-16 20:07:59.8834 [PID=3821 ] [send] stopping work search - daily quota exceeded (13>=4)

Is the daily limit per-host or per-account?

The daily limit is per host so other hosts should not be affected.

I think the above message means that the host already had been sent 13 tasks for the current day and that the limit was now 4 at the time the request for work was processed.  If your host is quad core, that's one task per core.  We are now in a new day so if you reset the project (if you haven't done so already) and beta tasks are allowed you should be able to get 4 new tasks - but that's all for the moment.

To prevent a 24 hour backoff from being immediately applied, you should prevent the host from making a further work request (use no new tasks) until you have some completed work to send back.  When you have a completed task, 'allowing new tasks' will allow it to be reported with a new work request and this will cause the scheduler to double your daily allowance from 4 to 8.  Rinse and repeat and you will quickly get back to your full allowance.  If you are already in a new 24 hour backoff, you can cancel that with a new 'update' request once you have a completed task to send back.

 

Cheers,
Gary.

JamieOnUbuntu
JamieOnUbuntu
Joined: 4 Oct 15
Posts: 11
Credit: 1542971
RAC: 0

Hi, The daily limit expired

Hi,

The daily limit expired and it requested 4 new tasks, however it still requested the same v1.42 tasks. Only the beta v1.47 tasks work on Raspberry Pi + Debian Stretch.

I have <allow_beta_work>1</allow_beta_work> set (also on the web interface), however it didn't seem to fetch beta work.

Is there a way to force it to fetch only beta work?

Thanks

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109383146151
RAC: 35952845

Your computers are hidden so

Your computers are hidden so I can't check anything on the website.  The quickest way to see what the issue might be is to go to the scheduler logs for that machine to see why the scheduler decided to send you what it did.  There is a pinned post on the Getting Started board that gives instructions about using the scheduler logs if you need assistance.

You should be able to see the various decisions the scheduler made in deciding what to send.

Quote:
I have <allow_beta_work>1</allow_beta_work> set (also on the web interface), however it didn't seem to fetch beta work.

You seem to be implying that you set a flag in two different places??  I only know of one - the project specific preferences on the website which doesn't involve any xml code but just clicking a yes/no setting and then saving.   If you placed that xml code in a file, which file?  If you really did change the setting "on the web interface", do you remember clicking the 'yes' option and then clicking the 'Save Changes' option down the bottom left hand corner of the page?

If you did properly make the change, the immediate thing that springs to mind is that the preference for allowing beta tasks might have been set in a location (aka venue) that is not the one your host is actually in.  Do you use different locations at all?

 

Cheers,
Gary.

JamieOnUbuntu
JamieOnUbuntu
Joined: 4 Oct 15
Posts: 11
Credit: 1542971
RAC: 0

Hi,Thanks for your

Hi,

Thanks for your reply.

The configuration file that I am referring to is /var/lib/boinc-client/account_einstein.phys.uwm.edu.xml. Upon setting the "Run Test Applications" options on the web interface and issuing an "Update", the <allow_beta_work> flag was set in the config file.

I have just done a fresh project reset and it seems to have fetched 4 v1.47 tasks. I am now seeing 4 tasks downloading and starting to run, and the CPU is back at 100% usage with 4 Einstein processes. Hopefully it is all working now!

Thanks for your help, I'll let you know how it goes after a few days. :)

By the way, if you are interested I have live stats available on my website here: https://www.jamieweb.net/projects/computing-stats/

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109383146151
RAC: 35952845

JamieOnUbuntu wrote:The

JamieOnUbuntu wrote:
The configuration file that I am referring to is /var/lib/boinc-client/account_einstein.phys.uwm.edu.xml. Upon setting the "Run Test Applications" options on the web interface and issuing an "Update", the <allow_beta_work> flag was set in the config file.

OK, thanks for that.  I learned something new today.  Many years ago (~8-10), the account file was a lot simpler, just containing the project name, the master URL and the authenticator that allowed the project to recognise a particular host as belonging to a particular account at that project.  That's when I set up 'templates' to copy into place instead of going through an installation followed by a massive download of all the files that would be needed.  So at some point along the way, that file seems to have been 'upgraded' so as to store local copies of project preferences.  I had never noticed - I've never needed to browse account files post installation.  The extra information just gets added (it seems) and presumably continuously updated from sched_reply messages from the project.

I would think you would need to check if this were a two-way process.  It seems very likely that a change at the project would always (after the next contact) result in a local change to that file.  I'm not at all sure the reverse is true.  Have you actually checked that making a local change results in that change appearing on the website?  I haven't since I can't see myself wanting to do it that way ;-).  If you are going to use that, you should test it in case a local change just gets reverted after a subsequent sched_reply from the project.

In any case, for modifying project preferences which usually are designed to modify the behaviour of the scheduler, there doesn't seem to be much sense in doing it locally and then having to rely on the changes being sent to the project through the next sched_request.  The scheduler can't know about it until after that.  If you change the setting on the website, the scheduler will know immediately.

JamieOnUbuntu wrote:
I have just done a fresh project reset and it seems to have fetched 4 v1.47 tasks. I am now seeing 4 tasks downloading and starting to run, and the CPU is back at 100% usage with 4 Einstein processes. Hopefully it is all working now!

Good to see you have got it sorted out!

I had a quick look at various things on your website.  Looks very nice!!  Well done! :-).

 

Cheers,
Gary.

PorkyPies
PorkyPies
Joined: 27 Apr 16
Posts: 197
Credit: 28020629
RAC: 8947

JamieOnUbuntu wrote:By the

JamieOnUbuntu wrote:

By the way, if you are interested I have live stats available on my website here: https://www.jamieweb.net/projects/computing-stats/[/quote]

That looks nice. I guess master is providing the web server and the status of each node seeing as its running a bit cooler and has more free memory.

I run BOINCtasks on my laptop to keep an eye on the farm which has a mix of amd64 machines and 10 Raspberry Pi3's.

JamieOnUbuntu
JamieOnUbuntu
Joined: 4 Oct 15
Posts: 11
Credit: 1542971
RAC: 0

Hi,The master is a

Hi,

The master is a Raspberry Pi 2B which is running E@H, the 4 nodes are all Raspberry Pi Zeros which are also running E@H. They are connected to the master Pi via USB (Ethernet gadget mode) with internet forwarding with iptables.

I think that the master has a lower temperature since it is nearest to the fan, and also separated from the 4 nodes which are piled on top of each other.

The web server is a separate machine that is also running Rosetta@Home as well as the Bitcoin node.

 

It sounds like you've got a pretty nice setup with 10 Pi 3's, do you know how the Pi 3 performs compared to the 2B when it comes to E@H?

Thanks :)

JamieOnUbuntu
JamieOnUbuntu
Joined: 4 Oct 15
Posts: 11
Credit: 1542971
RAC: 0

Thanks for your help with

Thanks for your help with this Gary :)

When I set the "Run Test Applications" option on the web interface, I noticed that the <allow_beta_work> flag was set in the local config.

As far as I know, updating the local config does not update the web config, although as you say it might be worth testing just out of interest.

The first batch of tasks have been completed and submitted, so my daily limit has gone up now.

Looks like it's all back to normal!

Thanks again!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.