Not Getting Credit

Your host started downloading the O2AS GW test tasks around 18th Aug with more of them on 25th Aug and later.  The 08/18 tasks were V1.07 and the 08/25 and later tasks were a newer test version V1.08.

The very first tasks returned from the 08/18 batch started exceeding the deadline on 09/02 but you did have a couple that seem to have made it back and got validated around 09/03.  So the first part of your problem was simply tasks not being crunched in a timely manner.

On top of that, both the mentioned versions are test versions of a new app so I imagine you must have changed your settings to allow your host to run test apps.  I'm sure the project is grateful for this support but you really need to be aware that test tasks are likely to fail or give invalid results so shouldn't be accepted if you want well behaved and stable performance with good prospect of validation.  You also need to follow the messages that can tell you if there are problems or not.

For example, on 08/26 Bernd posted this message confirming problems with V1.08 and that the app version was "retracted/deprecated".   By following the messages, you could have saved a lot of pointless crunching where everything labeled V1.08 was destined to be invalid.

I'm very sorry that you've been caught like this.  Hopefully, those who contribute to testing will eventually see some reward for their suffering in the form of an app that does give valid results.  We are not there yet as the return to the V1.07 app still shows significant numbers of results failing validation.  There is obviously more work to do and there is no clear answer as to why or how and when there will be progress towards the final goal of a stable app.

I believe I can tell you what caused you to get excessive downloads.

When I originally looked at your tasks, I selected just the GW GPU tasks because you mentioned them specifically in your second message.  Now that you mention excessive downloads without changing your work cache size, that suggests a duration correction factor (DCF) problem that might have been caused by running of some FGRPB1G tasks at about the same time as the O2AS GW tasks.  Sure enough, on inspection, there are still a couple of FGRPB1G tasks completed around Aug 26 and still showing in your tasks list.

It just so happens that FGRPB1G tasks crunch faster than their estimate whilst O2AS tasks take way longer than the estimate.  DCF is project wide so fast finishing FGRPB1G tasks will reduce DCF to such an extent that when your host went to download O2AS tasks, your BOINC client would have asked for a certain amount of work but then been given GW tasks to fill that request based on an entirely unrealistic estimate of how long the tasks would take.

To counter this problem there are several strategies you could use:-

• Choose one search only as the DCF will then settle over time to a value that will give the correct number of tasks for the work cache size you require.

• If you'd like both searches concurrently, just keep a very low cache size (eg. 0.2 days) so that even a wildly incorrect estimate of crunch time couldn't allow you to get anywhere near the 14 day deadline.  It will look very messy because sometimes you will have much more actual work than you should and at other times you will have much less.  However, with the low cache size you could essentially 'set and forget'.  Your main risk would be running out of work if there was a project glitch of some sort.
• If you're prepared to monitor things occasionally, you could alternate the two searches through preferences on a time scale of your choosing - perhaps several days or more.  Let's say you chose a week.  Start with a low cache size with just one search selected.  Once you have done a few tasks and the estimate is looking 'within the ball park' you could increase the cache size and then forget about it for the remainder of the week.  At the appropriate time, you would set the work cache to a low value again and then change the search to the other one.  Any new tasks will be for the other search but you won't get too many.  The remaining tasks for the previous search selection will be crunched.  When the new search tasks start being crunched there will be a DCF adjustment and once again, when that settles, you can increase the work cache to what you would like to have.  The disadvantage is that you have to keep remembering to do the pref changes (work cache and search type) at the appropriate times.  In other words, you have to do a bit of micro-managing on an ongoing basis :-).

 I hope this is all understandable.