Einstein@Home

BOINCStats:
http://einstein.phys.uwm.edu/

Project's new URL:
https://einsteinathome.org/

By not using the correct URL, user could accidentally add the project twice, since BOINC Manager Project>Add uses the correct URL.
Please fix BOINCStats.

This is a notice I got today:

Einstein@Home: Notice from BOINC
This project is using an old URL. When convenient, remove the project, then add http://einstein.phys.uwm.edu/
Mon 11 Sep 2017 11:42:06 AM PDT

I asked the project, here.
Hopefully they can provide the answers.

https://einsteinathome.org/content/einsteinhome-project-master-url

Could you please change it back to:
http://einstein.phys.uwm.edu/

Apparently, there is a URL translation bug, that remains unfixed in either/both the account manager server and client.
Christian Beer (admin at Einstein@home), is requesting BOINCstats to change it back.

Sorry for any confusion. We should get this bug fixed!!
- Jacob

Christian's reply regarding the problem:
https://einsteinathome.org/content/einsteinhome-project-master-url#comment-161748

I was afraid that would happen. Changed it back.

Thanks Willy. Again, sorry. Also, it looks like we may have exposed some other client issue, where it gets in a wonky delayed detach state, and ends up contacting BAM every 10 seconds infinitely (at least, for me!) I wrote about it to BOINC Alpha, and I hope this doesn't destroy your bandwidth. I've made a note to send an additional donation this month.

Jacob,

I saw your note on the list. I'm not currently participating but I still scroll...err read the messages. You beat me to repoting it. An extra note for that report is this seems to be an issue with the new BOINC client. I reverted back 7.6.3 and it was able to figure it out. I could not get rid of Einstein on 7.8.2 even after detaching from BAM. Also, the client kept trying to contact BAM even I detached.

~Yav

In the aftermath of this mess, what do I need to do in order to clean the situation up on my hosts removing the detach when out of work flag and resuming getting work from the project?

That's a good question.

I believe BOINC 7.8.2 has a bug where delayed detach doesn't work, and BOINC gets stuck in a loop, attempting it every 10 seconds and contacting BAM! every 10 seconds. David Anderson, who is owner of the BOINC code, has reproduced the problem and is working on a fix.

For now, a workaround is to:
- Use Tools > Stop using BOINCstats BAM!...
- Remove the project that was stuck in the delayed-detach-loop.
- Use Tools > Use account manager, to setup BAM! again.

In the end, this "mess" helped bring to light 2 issues that the BOINC community needs to solve:
1) The delayed-detach-loop (a real immediate problem)
2) URL redirection when being added by an account manager (a nuisance that prevents the account manager from using redirect URLs)

Jacob

My systems are still all on Boinc 7.6.x versions; so 7.8.2 specific bugs aren't a problem for me in trying to get things back to normal.

The devs think the problem is specific to BOINC 7.8.2.

So, it's entirely possible (probable even?), that you don't have to do anything, and that your hosts will manage detaching and flag clearing all automatically and correctly. That's my understanding, at least. Maybe you can let us know after a couple days

Events so far are not filling me with confidence on automatic recovery.

Of my two CPU only systems, one detached/reattached on its own. The second however did not even with repeated attempts to trigger it manually by forcing bam updates and dis/reconnecting to BAM. I eventually manually added the project while disconnected from BAM and it's left it alone since then.

My GPU boxes are going to be another story though; and will be a mess. E@H doesn't use creditnew, and the ~5x disparity between where the single DCF value should be for CPU and GPU tasks means that if I do nothing, I'll end up running backup GPU tasks for a week+ while my much longer CPU backlog is cleared. And if I mass abort CPU tasks so the two types run out at about the same time I'll end up in purgatory on E@H with an initial quota of only 1 or 2 tasks and a very long backoff before being able to request more automatically.

Maybe it's possible you could disconnect BAM, then close BOINC, then hijack client_state.xml to cleanup a flag or two, then open BOINC, then reattach BAM.

Seems like a possibility to me, but if it were me, I'd disconnect network adapters and make a backup copy of my data folder, and perform the operation and test offline for a bit, before reconnecting the network adapters.

Zapping the <detach_when_done/> tag did the trick.