Completed Too Late To Validate - the Hostage AP 5.05 Work Units

In the case of the AP work units being held hostage this is a problem of flagging the wrong user as submitting results too late.

There have been several posts on this topic but the short story is that many of us received AP work units when one or more computers failed to report results by the scheduled deadline. Sometime after, be that days or weeks late, the offending overdue results were reported before those with the replacement work unit could report. As a result the system validated the results using the late work unit and those of us that reported work in a timely manner had those results held hostage because no wing result could be generated or returned. These are some examples of threads discussing this problem:

http://setiathome.berkeley.edu/forum_thread.php?id=67959
http://setiathome.berkeley.edu/forum_thread.php?id=67740
http://setiathome.berkeley.edu/forum_thread.php?id=67382

Earlier today I noticed that my tasks in this situation have been invalidated although credit had been granted.

I will copy the above into my original post to keep everything together and avoid misinterpretation.

I agree that the "Completed, too late to validate" status looks like a black mark, but if BOINC managed to delete the canonical result before the last wingmate had uploaded and reported it's the simple truth. I think the project staff is doing the civilized thing by granting credit.

I had noticed a large surplus of "Results waiting for db purging" before, that was an indication that the associated files had been deleted. What isn't clear was how that related to the large "Results returned and awaiting validation" count.

For those users whose BOINC core client failed to get the tasks completed before deadline to be blamed, one has to assume the user had done something wrong. I think in most cases it reflected a flaw in BOINC instead, and giving credit for the uploaded results which matched makes more sense than punishing them.

I agree that the "Completed, too late to validate" status looks like a black mark, but if BOINC managed to delete the canonical result before the last wingmate had uploaded and reported it's the simple truth. I think the project staff is doing the civilized thing by granting credit.

I had noticed a large surplus of "Results waiting for db purging" before, that was an indication that the associated files had been deleted. What isn't clear was how that related to the large "Results returned and awaiting validation" count.

For those users whose BOINC core client failed to get the tasks completed before deadline to be blamed, one has to assume the user had done something wrong. I think in most cases it reflected a flaw in BOINC instead, and giving credit for the uploaded results which matched makes more sense than punishing them.

Joe

Thanks for the clear explanation, Les.

Can you hang on to that idea, please, and keep it (plus some sample data) for use in evidence. With this sudden breaking of the log-jam, and the rapid database purge settings at SETI, there's a danger that lessons for the future may be lost: we haven't even tried to work out whether the workunits have been held hostage by a SETI mis-configuration, or some flaw in the underlying BOINC code. I had hoped that when we got down to zero, the staff would have a chance to turn a keen analytic eye on the problem, but instead they seem to have swept it under the carpet - until the time comes for APv6 to be replaced.

Thank You Richard. I performed a screen capture of the Work Unit for tasks directly affecting me/my computer but these task/work units will be purged by this time tomorrow.

As I have complained about in related posts the additional problem is that since the task was validated without considering the work unit that was submitted in a timely manner then the assignment of canonical result was flawed because valid work was ignored. While the differences may be small between the actual analyses, it precludes proper crediting of results because the best analysis was ignored.

As Josef pointed out, there was a decision made as to whom to punish for this problem. I prefer that the offender be punished, not the person or computer that played by the rules and reported results in a timely manner.

I'll just keep my eye on these two v6 AP's to see if the same v505 problem occurs again. ;)

http://setiathome.berkeley.edu/workunit.php?wuid=953687194

http://setiathome.berkeley.edu/workunit.php?wuid=961583113

Cheers.

I would have thought that returning a result after the deadline would mark the task as "to late to validate". Also the validator running while there are tasks "in progress" doesn't make much sense. I imagine there is no logic to check for a condition that "shouldn't exist". However it does. So hopefully the BOINC server dev guys have one or both defects in their queue for "will be fixed".

Well, it works for MB, if a result is returned after the deadline, the validator waits for the resend and validates all 3 (or more) at once, hence we don't have such issues with MB.

Optimal would be to pre-validate the both results and if they are OK cancel the resend on the next sheduler request of the host, which has it. BOINC can do that. Otherwise, if it gets reported on the next request, than revalidate all 3 together.

I would have thought that returning a result after the deadline would mark the task as "to late to validate". Also the validator running while there are tasks "in progress" doesn't make much sense. I imagine there is no logic to check for a condition that "shouldn't exist". However it does. So hopefully the BOINC server dev guys have one or both defects in their queue for "will be fixed".

Well, it works for MB, if a result is returned after the deadline, the validator waits for the resend and validates all 3 (or more) at once, hence we don't have such issues with MB.

Optimal would be to pre-validate the both results and if they are OK cancel the resend on the next sheduler request of the host, which has it. BOINC can do that. Otherwise, if it gets reported on the next request, than revalidate all 3 together.

I dont like the idea of BOINC cancelling the resend especially with APs. On my slower PC, an AP takes 20 hours to process. If I had been processing it for 19.5 hours when the WU was cancelled I would be most displeased about the waste of my bandwidth, electricity and PC resources, to put it mildly!

I would have thought that returning a result after the deadline would mark the task as "to late to validate". Also the validator running while there are tasks "in progress" doesn't make much sense. I imagine there is no logic to check for a condition that "shouldn't exist". However it does. So hopefully the BOINC server dev guys have one or both defects in their queue for "will be fixed".

Well, it works for MB, if a result is returned after the deadline, the validator waits for the resend and validates all 3 (or more) at once, hence we don't have such issues with MB.

Optimal would be to pre-validate the both results and if they are OK cancel the resend on the next sheduler request of the host, which has it. BOINC can do that. Otherwise, if it gets reported on the next request, than revalidate all 3 together.

I dont like the idea of BOINC cancelling the resend especially with APs. On my slower PC, an AP takes 20 hours to process. If I had been processing it for 19.5 hours when the WU was cancelled I would be most displeased about the waste of my bandwidth, electricity and PC resources, to put it mildly!

I dont get it...

I dont see how is it possible to miss valuable data due to this situation...
If there are 2 matching results that were validated and there is something different in the 3rd result then this last result has to be the wrong one.

If some data is going to be lost its not by this issue about the hostages. It will be because the differences between apps for different hardware where it can happen that the matching results are not the best ones. But that will happen anyway, hostages or not...

Is there something else that Im not seeing/knowing?

I just found 3 5.05 units that should have cleared last year, but finally came up invalid.
http://setiathome.berkeley.edu/results.php?hostid=5483835&offset=0&show_names=0&state=4&appid=

Steve
____________
Warning, addicted to SETI crunching!
Crunching as a member of GPU Users Group.
GPUUG Website