Application selection
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4312
Credit: 250418682
RAC: 35172
6 Feb 2013 15:36:23 UTC
Topic 196791
(moderation:
Here's the thing:
In the preferences participants can select which applications (apps for short) to run of a project. This is neither a clear opt-in nor an opt-out. It is implemented as an opt-in (per app), but when you didn't make any selection yet, your choice is actually taken to run any app of the project, not none. So as long as you hadn't opted-in to the opt-in, it's treated as an opt-out.
This is not only inconsistent and confusing, it also assumes a static set of apps on the project. For projects like Einstein@Home that regularly phase apps in and out (e.g. our "GW runs"), this leads to problems for everyone who ever made any app selection:
* A client will not get work for new apps until the preferences are edited again
* A checkbox for an app will not appear on the preference page when this app has been "deprecated" (phased-out) by the project. Depending on the previous selection there may not even be the possibility to enable all apps again and switch back to the "opt-out" behavior.
To (partially) make up for this, BOINC offers the standard setting "If no work for selected applications is available, accept work from other applications?". This in turn has a few problems on its own, at least on Einstein@Home:
* It never really worked as it should on Einstein@Home. This mainly has to do with limitations of the "mixed scheduling" that we use here. Essentially we are calling two different schedulers for "locality" and "non-locality" work, both of which have been programmed with the assumption that each is the only scheduler running on this project.
* A client will only get work for new applications when there is really no work for any other selected application. In current case this means that e.g. the client will not get any work for FGRP2 or S6BucketLVE as long as there is still (CPU) work for BRP4. I think in general this is not what participants actually want.
Finally a client that doesn't get (new) work is not only a problem for the participant, but also for the project. Over time, more and more computing resources get shifted to older apps, new apps getting less resources than what may be wanted and expected.
I currently think of replacing this "If no work for selected applications is available, accept work from other applications?" setting by something like "Automatically accept work for new applications that are not yet published". The default would be "yes", but participants could opt-out if they want to manage app selection themselves. This would mean that whenever a new application is added to the system, any participant who ever made an app selection (i.e. has any tag in the project preferences) and has this choice set to "yes" would automatically get added the new app to his selected apps.
I would appreciate comments and am open to discuss alternative solutions to that problem, as long as these can be implemented with reasonable effort.
BM
BM
Application selection
)
I like this.
In fact I think that accepting automatically new apps should be the default and there is no need to opt-out of this behaviour, first because we can always opt-out for the specific apps once they start to appear on the BM client but also because having the option to set the prefferences to not accept new apps will cause the same troubles that the current way... Anyway, having more options and more control is always a nice thing.
RE: I currently think of
)
I like the idea of the new option to automatically accept work for new applications. I am also okay with having any new applications enabled by default. I think this would be handy in cases where not everyone is aware right away that a new application like GW Search (extended) has been added.
@ Bernd Machenschalk. I
)
@ Bernd Machenschalk.
I know I have not seen the new units for the BRP4 applications 1.34 only the 1.33 so far. While the more control is always nice the older apps need to get done as well. I fear most would skip on the older apps to run the newer 1's for points or whatever. No matter what you do I will leave my computer to run whatever it gets when it gets. You can try it and see how it goes and make changes along the way. I do like the idea of this. Something I think could help is making the settings all in 1 page " Computing preferences and Einstein@Home preferences" but things may be needed tweaked in Boinc client for that to work.
Though I am stopping work for a bit for moving this weekend but once moved I will be back up running. Just thoughts of Nobody316
PC setup MSI-970A-G46 AMD FX-8350 8 core OC'd 4.45GHz 16GB ram PC3-10700 Geforce GTX 650Ti Windows 7 x64 Einstein@Home
RE: RE: I currently think
)
+1
I support this. I have turned
)
I support this. I have turned off the "accept work from other applications" because I want to keep BRP4 work to the GPU and I believe I had to opt-in manually to new apps after I noticed no new work was coming. Changing preferences later is better than running out of work.
"Automatically accept work
)
"Automatically accept work for new applications". default "yes",
participants can opt-out later if they want to.
now that i think about it i am supprised it is not this way already.
RE: I know I have not seen
)
This thread is about applications; what you are talking about is what we call application versions and is a different thing. Usually BOINC doesn't allow you to select individual application versions at all.
FWIW "Binary Radio Pulsar Search" (BRP4) application versions 1.33 and 1.34 are identical, the only difference is that the BOINC code ("API") linked into the 1.33 versions didn't work for OpenCL (and Linux CPU), so we built new application versions 1.34 for just these platforms.
BM
BM
I'm also in favor of
)
I'm also in favor of automatically enabling new applications by default.
When I add a new project, at first I come back fairly frequently to look at my settings and tweak things a bit. But after a while, I tend to just leave the project running on auto-pilot and rarely re-check my application choices or other settings.
And I'm sure a lot of other people are like me: once a project is no longer new to the user, the settings just don't get checked very often.
I like this this.
)
I like this this.
RE: I like this
)
Well, that was a description of the status quo, and we would like to give the volunteers additional options that would allow them to participate in new runs without explicit opt-in, IF they want to. The question is how to implement this is the most user-friendly way possible.
Cheers
HB