Possible conflict between pref settings for "Run test Apps" and "Run selected Apps"
5 Feb 2016 2:20:50 UTC
Topic 198406
(moderation:
Maybe the behaviour I observe is intended - I hope not! :-).
I have "Run test apps" enabled because I'm willing to try out new versions. I use the "Run selected apps" to choose which particular Science runs I participate in. Until FGRPB1 appeared, the only selected runs were BRP6 and FGRP4. FGRPB1 was auto-selected when added to the list and I'm fine with that. I expected that.
I got 10 tasks all told from the very first batch of 100 FGRPB1. They were announced as beta test tasks. At that point, I wanted to see how this first lot went before allowing more so I removed the selection for FGRPB1 on all 4 venues, thinking that would prevent any further tasks. There has been a further, somewhat larger release of tasks. I presume they are a continuation of the beta test. I was surprised to see a further 90 tasks arrive even though I had deselected the run.
I don't really have a problem with this (since nothing bad happened) but I was hoping to be able to better control the take up of the first (test) tesks in a new run without risking the whole fleet if something goes wrong :-). I thought I'd done rather well by having only about 5 machines running the first batch. I've now got a very much larger number of hosts crunching away :-).
For future reference, I'd like to know if 'allowing test apps' applies to any science run (selected or not) or should I be able to restrict it by 'turning off' the selection of a particular run? Perhaps I stuffed up in some way in how I deselected FGRPB1. My project pref settings still show that box as clear (no tick mark). I expected the removal of the tick (which was well before the 2nd bigger release) would have prevented any more than the original 10 tasks.
Cheers,
Gary.
Possible conflict between pref settings for "Run test Apps" and
)
How about the timing of your change to the preference, vs. host updates?
I think when this system is working as intended, a revised task selection preference does not take effect until after the next host update, which leaves a window of opportunity for a work request by your host to get filled under the old rules before the revision takes effect.
You have a large fleet, and perhaps as an efficiency minded guy you have your communication settings at values which discourage excessively frequent updates. Could it be that all the hosts that got this work got it on their very next update communication?
If that is not it, then it sounds to me as though there is a bug somewhere.
RE: ... a revised task
)
You might be correct but I thought that since the change was made on the website, the scheduler would have immediate access to the changed settings. Subsequently, a client making a work request communicates with the server and the scheduler sees a request for X amount of CPU work. The scheduler presumably consults the preferences to see which type of CPU work it is allowed to send. Because of what gets transmitted with a work request, it is effectively an 'update' anyway.
I don't think so. Under script management, every host gets it's work cache settings temporarily increased and then returned to normal every ~3.5 hours. Most often this triggers a project communication for work fetch. My recollection is that the FGRPB1 run was turned off more than 12 hours before the second release of FGRPB1 tasks was made - plenty of time for individual hosts to have been forced into a project communication.
Or it's intended that agreeing to beta test work means that you could get such tasks from any science run, irrespective of whether or not you have selected a particular run. I don't mind if this is the case. I'd just like to be aware of it for future reference.
Cheers,
Gary.
Gary: I'm not sure how this
)
Gary: I'm not sure how this works right now. I have to look in the Code or ask Bernd on Monday. My personal hunch would be that if you select Beta apps and there is a Beta app, than the app selection preference is ignored. Just like you experienced.
RE: Gary: I'm not sure how
)
My recollection of the code - at least the one currently running on Einstein - is the same: When checking that a given app can be send to a client and the app is a Beta app, it is only checked whether the owner of the client as agreed to receive "Beta" work, and not further whether is is in the list of allowed apps.
Good or bad, that's how the code currently works.
BM
BM
RE: ... but I thought that
)
Sorry, I saw this this morning and meant to reply, but as always real life intervened.
Strangely, the same question came up at SETI a week ago, and I tried to answer it in SETI message 1760307. Perhaps it would be helpful to repeat it here - you'll need to translate application names, but the rest should be applicable.
So, my understanding is that if you have long-standing preferences that exclude particular hardware types, you should never get an unexpected work allocation for an application which uses that hardware - because your client will have requested zero seconds of work.
But if you allow work for the hardware, and you allow Beta applications, you may sometimes be surprised by work for a new Beta application you hadn't specifically selected.
The SETI thread meandered on a bit further, but ended with this rhetorical exchange: