Referring to the August 18 technical news bulletin:

"Such results can appear when a workunit had reached it's quorum number of returned results and is passed through validation, assimilation, file (both workunit and result) deletion and finally DB purging and *then* one or more results come in (perhaps they were slowed down by running intermittently on a laptop). The disassociated results are the bulk of what needs deleting."

So if the backlog of results awaiting validation are these "orphaned" results that are received after they have already reached quorum, does this mean that no credit is going to be issued for them? It's not very fair. Why should someone get credit because they returned a workunit inside the deadline and not if they are late? Sure, only three results are needed for a quorum, but discriminating in my mind violates the spirit of BOINC whereby credit is a reflection of CPU work DONE, not work USED TO ESTABLISH QUORUM. If you "order" something and then say you don't want it when it's delivered, you still have to pay for it!

---

---------------------------------
Nathan Zamprogno
http://baliset.blogspot.com

... Why should someone get credit because they returned a workunit inside the deadline and not if they are late?...

It is these late results that are causing the backlog in the first place. If all units were returned within the initial deadline then the database could be regularly purged properly and subsequently the validation process work quicker and there wouldn't be such large backlogs.

It would be preferable if everbody who isn't restricted by using modems or regularly moved laptops etc. left the connection option at the default or at a reasonably low figure. This decreases the number of results that have to be kept in the database and reduces the incidence of late returns.

Andy

does this mean that no credit is going to be issued for them? It's not very fair. Why should someone get credit because they returned a workunit inside the deadline and not if they are late?

If you return inside the deadline you get the Credit

---

Does someone want to look up the definition of 'deadline'

---

Does someone want to look up the definition of 'deadline'

Actually the correct term is Result Deadline

---

Referring to the August 18 technical news bulletin:

"Such results can appear when a workunit had reached it's quorum number of returned results and is passed through validation, assimilation, file (both workunit and result) deletion and finally DB purging and *then* one or more results come in (perhaps they were slowed down by running intermittently on a laptop). The disassociated results are the bulk of what needs deleting."

So if the backlog of results awaiting validation are these "orphaned" results that are received after they have already reached quorum, does this mean that no credit is going to be issued for them? It's not very fair. Why should someone get credit because they returned a workunit inside the deadline and not if they are late? Sure, only three results are needed for a quorum, but discriminating in my mind violates the spirit of BOINC whereby credit is a reflection of CPU work DONE, not work USED TO ESTABLISH QUORUM. If you "order" something and then say you don't want it when it's delivered, you still have to pay for it!

If you turned in your book report in school a week late, were you still able to get an A on it? I rather think not. A deadline is just that. If a correctly processed result that is valid (matches other results for the same WU) is not returned by the deadline, it has to be sent off to someone else to process - hence no credit is a possibility for the late result.

---

BOINC WIKI

... Why should someone get credit because they returned a workunit inside the deadline and not if they are late?...

It is these late results that are causing the backlog in the first place. If all units were returned within the initial deadline then the database could be regularly purged properly and subsequently the validation process work quicker and there wouldn't be such large backlogs.

I think it's important to remember that these results aren't merely late. They aren't late by an hour, or a day.

They are well over the deadline. They are so late that the people who designed BOINC never anticipated the problem -- It didn't occur to them that there would be valid results returned far past the deadline.

---

They are well over the deadline. They are so late that the people who designed BOINC never anticipated the problem -- It didn't occur to them that there would be valid results returned far past the deadline.

John, Ned, whoever...

When we speak of disassociated result files that have no corresponding row in the database... as per Matt's post... are we speaking only of results that were submitted after the deadline, or are there other factors that may have contributed to these orphaned files? It seems that if it were only a matter of missed deadlines, then the files should simply be deleted and nobody has a right to complain.

I have no credits pending so my interest is certainly not to bitch about the situation... only for information value.

Thanks,

Dig

John, Ned, whoever...

When we speak of disassociated result files that have no corresponding row in the database... as per Matt's post... are we speaking only of results that were submitted after the deadline, or are there other factors that may have contributed to these orphaned files? It seems that if it were only a matter of missed deadlines, then the files should simply be deleted and nobody has a right to complain.

I have no credits pending so my interest is certainly not to bitch about the situation... only for information value.

Thanks,

Dig

No, there are several cases. But in general, the solution will need to be to delete the orphans as soon as they can be detected.

1) If a report is made too late (after verification and deadline) just delete the result file - it is not going to be used for anything anyway.
2) After a result is verified, look for strays that were uploaded and not reported.
3) When a result is moved to the science database, search for strays and delete.
4) The remaining case is going to be difficult - those that are uploaded after verification, deadline, and the move to the science DB that are never reported. These, I suspect will need to be swept up by a daemon that periodically sweeps through the upload directory.

---

BOINC WIKI

No, there are several cases. But in general, the solution will need to be to delete the orphans as soon as they can be detected.

1) If a report is made too late (after verification and deadline) just delete the result file - it is not going to be used for anything anyway.
2) After a result is verified, look for strays that were uploaded and not reported.
3) When a result is moved to the science database, search for strays and delete.
4) The remaining case is going to be difficult - those that are uploaded after verification, deadline, and the move to the science DB that are never reported. These, I suspect will need to be swept up by a daemon that periodically sweeps through the upload directory.

#1, no problem.
#2 and #3, both Validation and Assimilation will normally happen before 4th result in, so any "strays" can still be reported normally. A better solution is to let db_purge look for strays, since SETI@Home normally waits 7 days from wu "done" this is a solution, but some projects is AFAIK running db_purge immediately after "done"...
#4 is the difficult part...

When we speak of disassociated result files that have no corresponding row in the database... as per Matt's post... are we speaking only of results that were submitted after the deadline, or are there other factors that may have contributed to these orphaned files?...

No, there are several cases. But in general, the solution will need to be to delete the orphans as soon as they can be detected.

Okay, thanks John. So there are at least some cases where credit should have been granted for these orphaned files.

Dig

They are well over the deadline. They are so late that the people who designed BOINC never anticipated the problem -- It didn't occur to them that there would be valid results returned far past the deadline.

If I had some whare the dealine passed a few Mo. ago I would not even run them. Just as easy to abort them and get new ones. Even with a dial up connection there is no reason to go 6 Mo. or a year and think they are still good when you can read the date in BOINC.

---

Pizza@Home Rays Place Rays place Forums

If I had some whare the dealine passed a few Mo. ago I would not even run them. Just as easy to abort them and get new ones. Even with a dial up connection there is no reason to go 6 Mo. or a year and think they are still good when you can read the date in BOINC.

I agree with you there, Ray. But it does seem that at least in some cases, the results were orphaned by reasons other than simply passing the deadline. Perhaps this is why the good folks at Berkeley are trying to resolve the matter as gracefully as possible. I have a lot of respect for their efforts. I was just trying to see all sides of the issue. :)

Dig