Allow non-preferred apps
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4313
Credit: 250761049
RAC: 33962
20 Oct 2017 11:08:12 UTC
Topic 210369
(moderation:
There is now a now / revived project preferences setting "Allow non-preferred apps" with the text "If no work for selected applications are available, accept tasks from other applications?", which is standard-BOINC. However I think this needs a bit more of explanation on Einstein@Home, as it works a little different here than on other projects.
On Einstein@Home we use two different "schedulers" to send tasks to the clients. One, the "locality scheduler", manages the Gravitational Wave searches (currently "O1Spot1") and applications. The other "array scheduler" manages all other searches (currently Radio- and Gamma-Ray Pulsar). The problem is that these two don't know know from the other one. So the setting only applies to all applications in each group. In fact it means "If no work for selected (BRP and FGRP) applications are available, accept tasks from other (BRP and FGRP) applications, AND if no work for selected GW applications are available, accept tasks from other GW applications?". Thus the results of this setting might be somewhat confusing.
I'm open for suggestions on how to further improve the situation, e.g. use two different settings for the different groups of applications.
BM
Bernd Machenschalk schrieb:
)
Consider placing 'Allow non-preferred apps' in the 'Applications' section rather than in the 'Other settings' section.
Then the 7 settings in the 'Applications' section could be divided in order to make up two groups of settings, separated by an empty line. The last line of each of the two groups could then be an 'Allow non-preferred apps of above listing' setting. This proposal makes sense only if two different 'Allow non-preferred apps of above listing' settings are technically feasible.
Bernd Machenschalk wrote:...
)
Yes, indeed! When Solling2's problem was being discussed in the other thread, I went through all my own project preferences looking for anything strange and noticed that setting which I couldn't remember seeing previously. Mine was set to 'No' for all locations so I assumed that must have been the default setting whenever it first appeared. I also assumed that if it was (intentionally or accidently) set to 'yes', it would only come into play if there was no work for an 'allowed' app. Because there was no apparent work outage at the time, I discounted it as a possible cause.
Having two separate schedulers that don't know about each other must cause some issues. To make it easier for people to be aware of this and plan accordingly, I agree that the suggestion to separate the two groups on the project preferences page would help. Under the APPLICATIONS heading, there could be two distinct sub-headings called something like 'Searches using Locality Scheduler' and 'Searches using Array Scheduler'. The apps with their tick boxes and the 'Allow non-preferred' yes/no setting for just those particular searches would then be clearly separated.
You may be able to achieve a solution to the current problem without having a second 'Allow non-preferred' setting. It seems to me that a 'yes' setting currently means 'allow tasks for an app in a particular sub-group even if no search in that sub-group is currently ticked'. If the logic of the code was changed to disregard the yes setting unless at least one search in that sub-group was ticked, the problem couldn't have occurred. In other words there would have to be at least one preferred app in a sub-group for a non-preferred app to even be considered. And even then, a non-preferred app should only be considered if there was no work for the preferred app.
Cheers,
Gary.