Pages: [1]
Jacob Klein
BAM!ID: 32925
Joined: 2007-08-21
Posts: 35
Credits: 5,480,086,049
World-rank: 392

2017-09-10 20:36:23

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.
labrat42
 
BAM!ID: 83261
Joined: 2010-03-25
Posts: 48
Credits: 1,889,003,913
World-rank: 826

2017-09-11 22:07:22

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
[size=11]labrat42 (formerly Bill42)
Jacob Klein
BAM!ID: 32925
Joined: 2007-08-21
Posts: 35
Credits: 5,480,086,049
World-rank: 392

2017-09-11 23:50:50

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

https://einsteinathome.org/content/einsteinhome-project-master-url
Jacob Klein
BAM!ID: 32925
Joined: 2007-08-21
Posts: 35
Credits: 5,480,086,049
World-rank: 392

2017-09-12 12:06:56

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
This is a known problem and stems from the observation that the Client makes a difference in how a project is added. In case of adding a project via the manager the new URL can be used because the manager is translating the new URL to the old URL before adding the project. In case of adding a project via an Account Manager only the old URL can be used because the client does not do the translation of new to old (and the account manager can't do that either according to boincstats).

That's why we could change the URL in the project list but not on BOINCstats. We tried that in the past but it lead to the exact notice you cite. So please ask boincstats to change it back.

~~~ Einstein@Home Project Administrator~~~
[BOINCstats] Willy
 
Forum moderator - Administrator - Developer - Tester - Translator
BAM!ID: 1
Joined: 2006-01-09
Posts: 9136
Credits: 348,241,820
World-rank: 2,973

2017-09-12 12:56:25

I was afraid that would happen. Changed it back.
Please do not PM, IM or email me for support (they will go unread/ignored). Use the forum for support.
Jacob Klein
BAM!ID: 32925
Joined: 2007-08-21
Posts: 35
Credits: 5,480,086,049
World-rank: 392

2017-09-12 13:07:30
last modified: 2017-09-12 13:08:31

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.
Yavanius
BAM!ID: 180363
Joined: 2015-01-26
Posts: 244
Credits: 10,553,947
World-rank: 38,912

2017-09-14 21:42:49

Jacob Klein wrote:


Christian's reply regarding the problem:
https://einsteinathome.org/content/einsteinhome-project-master-url#comment-161748
[quote]This is a known problem and stems from the observation that the Client makes a difference in how a project is added. In case of adding a project via the manager the new URL can be used because the manager is translating the new URL to the old URL before adding the project. In case of adding a project via an Account Manager only the old URL can be used because the client does not do the translation of new to old (and the account manager can't do that either according to boincstats).

That's why we could change the URL in the project list but not on BOINCstats. We tried that in the past but it lead to the exact notice you cite. So please ask boincstats to change it back.


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
DanNeely
BAM!ID: 2469
Joined: 2006-06-22
Posts: 78
Credits: 1,525,895,983
World-rank: 964

2017-09-14 23:16:41

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?
Jacob Klein
BAM!ID: 32925
Joined: 2007-08-21
Posts: 35
Credits: 5,480,086,049
World-rank: 392

2017-09-15 12:04:04
last modified: 2017-09-15 12:04:48

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
DanNeely
BAM!ID: 2469
Joined: 2006-06-22
Posts: 78
Credits: 1,525,895,983
World-rank: 964

2017-09-16 13:44:38

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.
Jacob Klein
BAM!ID: 32925
Joined: 2007-08-21
Posts: 35
Credits: 5,480,086,049
World-rank: 392

2017-09-16 14:17:12

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
DanNeely
BAM!ID: 2469
Joined: 2006-06-22
Posts: 78
Credits: 1,525,895,983
World-rank: 964

2017-09-16 14:48:49

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.
Jacob Klein
BAM!ID: 32925
Joined: 2007-08-21
Posts: 35
Credits: 5,480,086,049
World-rank: 392

2017-09-16 15:38:11

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.
DanNeely
BAM!ID: 2469
Joined: 2006-06-22
Posts: 78
Credits: 1,525,895,983
World-rank: 964

2017-09-17 15:21:57

Zapping the <detach_when_done/> tag did the trick.
Pages: [1]

Index :: The Projects :: Einstein@Home - Updated URL - https://einsteinathome.org/
Reason: