Completed, can't validate

Was looking through the results I had returned recently and noticed:

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

So because of client errors from other people, those who do end up returning valid results are going to effectively have their credits denied in future?

"Other people couldn't do it, so you can't have your credit even though you could" is hardly a way to keep your crunchers happy.

Just wait until you get people who aren't running optimised apps who take far longer to crunch each wu noticing this, fun times ahead me thinks.

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



Made your link clickable Mark. Sorry to see that happen.
____________


PROUD MEMBER OF Team Starfire World BOINC

Was looking through the results I had returned recently and noticed:

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

So because of client errors from other people, those who do end up returning valid results are going to effectively have their credits denied in future?

"Other people couldn't do it, so you can't have your credit even though you could" is hardly a way to keep your crunchers happy.

Just wait until you get people who aren't running optimised apps who take far longer to crunch each wu noticing this, fun times ahead me thinks.

Was looking through the results I had returned recently and noticed:

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

So because of client errors from other people, those who do end up returning valid results are going to effectively have their credits denied in future?

"Other people couldn't do it, so you can't have your credit even though you could" is hardly a way to keep your crunchers happy.

Just wait until you get people who aren't running optimised apps who take far longer to crunch each wu noticing this, fun times ahead me thinks.

Was looking through the results I had returned recently and noticed:

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

So because of client errors from other people, those who do end up returning valid results are going to effectively have their credits denied in future?

"Other people couldn't do it, so you can't have your credit even though you could" is hardly a way to keep your crunchers happy.

Just wait until you get people who aren't running optimised apps who take far longer to crunch each wu noticing this, fun times ahead me thinks.

Oh ye of little faith
the admins have blessed us with a new category different from PENDING - called VALIDATE INCONCLUSIVE - (as an explanation). Just got 2 of them and SETI was prioritized to process them and BINGO - IT WORKS. KUDOS to the admins -

http://setiathome.berkeley.edu/workunit.php?wuid=417873086
Here is one more: Completed, can't validate. So, I have stop crunch SETI because of that.

here is another 1178553096.
____________

RottenMutt,

Yours is a bit different from what they are talking about here. One of you doing this WU found 30 spikes and the other one didn't so it has been sent out to a third cruncher to see which is right. When the third cruncher completes this and sends it in two or all of you will get credit.

The WUs they are talking about in this thread were sent out one too many times and though the sixth man completed it successfully he can't get the credit because too many people had already errored out on it.
____________


PROUD MEMBER OF Team Starfire World BOINC

It looks to be shaping up to me having one of those too. My wingman appears to have gone astray on this one http://setiathome.berkeley.edu/workunit.php?wuid=417846562. He has until the 24th but I'm not holding my breath.
____________


PROUD MEMBER OF Team Starfire World BOINC

If that original wingman (_0) times out, the WU will still be alive, but it will all hinge on the last wingman (_6). The error limit is 5, which is inclusive..so up to, and including 5 errors. More than 5 will effectively kill that WU.
____________

Linux laptop uptime: 1484d 22h 42m
Ended due to UPS failure, found 14 hours after the fact

If that original wingman (_0) times out, the WU will still be alive, but it will all hinge on the last wingman (_6). The error limit is 5, which is inclusive..so up to, and including 5 errors. More than 5 will effectively kill that WU.

If that original wingman (_0) times out, the WU will still be alive, but it will all hinge on the last wingman (_6). The error limit is 5, which is inclusive..so up to, and including 5 errors. More than 5 will effectively kill that WU.

Ahh, good then there is still hope. I might get my credits in a month or so. :)

Guess I miscounted, I thought it was already up to the limit.

Well, the workunit looks to have been purged from the database now, the link now resolves to a page that contains a message saying "can't find workunit."

The situation sucks badly in my opinion, I just take some small comfort from the fact it was only 10 hours or so CPU time, although that's not going to be of comfort to other people if they run into the same sort of problem.

I'd hate to think how the people with only 1 older computer for instance and it takes 40 hours or more for them to crunch a single AP wu will feel.

I don't think that this policy has been thought through very well to be honest.

While I appreciate we are running seti@home by choice, it is nice to think that when we do, we will receive credit for the work we actually do. Not be told "tough, other people screwed you up by getting errors."

I would like to see a response from one of the actual seti team about this, with a positive message that they are at least aware of the issues and they are going to try to fix it.

It's not a policy issue, per se. The problem stems from the network issue that happened a few weeks ago and caused a TON of failed downloads. Under normal circumstances, even with some of the bugs in the app, one would expect there to never be more than 4 tasks for one WU. Compute errors happen for apparently no reason at all, but it's not predictable, so we just kind of hope for the best.

That network issue that caused a lot of failed downloads is a problem though. A task being aborted by the client because the application does not exist due to a failed download is a logistical problem, in my opinion. I think the client should not download any tasks until the application is successfully downloaded. That would have mitigated all of those issues with that network problem.

So, once we get all of those WUs out of the way that were involved in that network issue, things will be smooth sailing again, but we just have to get past the problem WUs. Some people will be burned by it, and though unfortunate, there's not really much that can be done about it. True there are going to be voids and holes in the science database since results were effectively just thrown out, but I think we may end up keeping the "tapes" that were affected and split them again at another date..maybe we have already.
____________

Linux laptop uptime: 1484d 22h 42m
Ended due to UPS failure, found 14 hours after the fact