Allow non-preferred apps

Bernd Machenschalk
Bernd Machenschalk
Joined: 15 Oct 04
Posts: 3739
Credit: 157705964
RAC: 58637
Topic 210369

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

solling2
solling2
Joined: 20 Nov 14
Posts: 58
Credit: 77341702
RAC: 250372

Bernd Machenschalk schrieb:

Bernd Machenschalk wrote:
e.g. use two different settings for the different groups of applications.

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.

Gary Roberts
Gary Roberts
Joined: 9 Feb 05
Posts: 4190
Credit: 10449374301
RAC: 24307294

Bernd Machenschalk wrote:...

Bernd Machenschalk wrote:
... Thus the results of this setting might be somewhat confusing.

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.

Bernd Machenschalk wrote:
I'm open for suggestions on how to further improve the situation, e.g. use two different settings for the different groups of applications.

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.

Comment viewing options

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