That sounds links an interesting thought. I would turn it around and encourage people positively:

Keep the current scoring and increase the credits if you return a task within a certain proposed time. That would be more of an incentive.

There's major problems with this idea. Those not interested or motivated by credits wouldn't change their behaviour.

And for users with a queue longer than a few hours - there's no guarantee that BOINC will choose to start and finish an ARP WU within that timeframe. It would probably punish a significant number of crunchers for the software's decisionmaking - or just cause people to turn it off altogether which is the opposite of what the monthly update has been pleading.

For example - I have a 1 day queue on a laptop running 4 CPU Cores at 100%, just MCM + 1 OPN. It received the WU on the 7th - it did not start processing the WU until the 11th, despite the queue size.

My understanding of the monthly updates has been that WCG and the ARP team are requesting that more machines run more ARP WUs. Unless there's a huge supply issue where a bunch of crunchers aren't receiving work, more WUs being processed overall is the issue - not the speed at their processing throttling the team's work. I could be mistaken, feel free to kindly correct me - but as far as I know, this is a solution to something which isn't yet a problem.

dayle - the vast majority of WCG volunteers do not participate in the forums - using the forum as a sample size to claim that volunteers do care about credits more than they care to admit, doesn't magically make this suggestion game changing for the project. Only a few dozen people changing their behaviour is not going to have a significant affect on the project.

the project's request was for more volunteers to contribute, and for existing ones to boost their contribution. If there was concern about queue size, the project would surely request users to reduce their queues? Why solve a problem that doesn't need to be fixed?

I know some users here are very against "large" queue sizes, regardless of the needs of the volunteer - but it has no affect on the project whatsoever, unless there is a shortage of WUs. This appears not to be the case, when this project is actively asking for people to take on more WUs, and on new users to contribute without any stated conditions beyond the RAM requirements. If WCG has an issue with the speed of work, they can simply just shorten the deadline and set CPU requirements as they so desire.

There's no need to play around with credit granted unless there is an issue that needs to be resolved - and shortening deadlines like FAAH2 did, seems like a far simpler and useful solution for if and when this becomes a problem.

There are no late responders if they submit by the deadline. If the grid shares this concern you have, they should decrease the deadline - not make a behind the scenes change to how points are calculated. Again, you have not presented why this change is necessary. ARP is running more WUs than before - there appears to be no shortage of WUs despite the increase in the flow of WUs. Unless there's a compelling need to make this change, I don't see why it's necessary to take such a drastic intervention - punishing volunteers who can't control when boinc starts and finishes a project - including the people in your example who couldn't finish a task within a shorter deadline and feel excluded. The same feeling of exclusion applies to punishing all who can't make this arbitrary 36 hour deadline. If the project needs a 36 hour deadline to be more efficient, it should be a 36 hour deadline.

Logging in to change settings doesn't require touching the forums. And the vast majority know the ARP project exists through the notifications, both from when it was announced and the monthly update notifications since last summer.

thanks for that context - this is precisely what I was asking for.

If entity did indeed take off after 16 years participating, that is obviously a huge disappointment.


entity said:
"I found the wait to be as long as one hour in some instances. I would run a longer queue so that work will be available to the thread during the "drought". I have removed my machines from ARP1 due to the lack of work."

A whole hour seems like a reasonable temporary shortage to me for a project. Just based on the context of that post, it seems that a longer queue was a solution which would have worked. As WCG tech knreed said in reply to entity's post -

"Great! You client will rotate through each each BOINC project asking for work and sometimes you will get a job from that project and sometimes not but overall your client will continuously do work for one of them. The same thing could be achieved just within WCG. You could sign up for African Rainfall Project, Help Stop TB and Smash Childhood Cancer (which are all intermittent project) and then check the box for "If there is no work available for the project(s) I have selected above, please send me work from another project.". If there is work for one of your preferred projects, then you will get it. If not, you will get work from Mapping Cancer Markers or OpenPandemics and your client will continuously process work. I do not see why you should unsign up from African Rainfall Project just because work is not continuously available for it."

I don't understand how this is WCG's fault, nor how this is a problem. The tech already wrote out quite clearly why there are intermittent shortages, and precisely why they encourage selecting multiple projects.

This post still assumes the volunteers - and their queue sizes are at fault for a "problem" which based on your example - blaming us for making entity quit, and these intermittent shortages?

Would the temporary shortages not be caused because more machines are requesting WUs? Jumping to the conclusion that queue is the problem, when there's no way to assess or prove that claim beyond more volunteers opted in? Can OP or you, prove that ARP WUs are ACTUALLY sitting idle in queues, and that they are the direct reason why there's intermittent shortages, when said shortages are expected and normal - sorta like how machines with short queues do? Frequently checking in and asking for 200 WUs every time is an irrational expectation when the project is upfront as intermittent from time to time. Look at HSTB - if this argument is valid, does OP's and some other volunteer's argument not apply to that project as well?

A quote from knreed a few days before the post you linked - "We have now reached a point with the African Rainfall Project where we are able to keep all of the work out and running so there are times where there will be no work available."

I've only been here a year and a bit - I don't see how this is a grid-side issue that needs resolution, nor do I think that a credit reduction for those not completely within 36 hours is fair - much less reasonable. If the grid sees intermittent supply as a problem - which I suspect they don't, nor do I think they should - then a shorter deadline seems like a far more effective and rational solution, if this problem genuinely needs to be tackled.