State: All (760) · In progress (122) · Validation pending (307) · Validation inconclusive (18) · Valid (308) · Invalid (0)

I don't remember having any inconclusive's in the past.
Is this just part of the new Boinc system , maybe a more detailed , closer check on the data ?

---

Thats normal.
Mostly its stock cuda thats missing one signal.
But you could also update to the new revision.

I always have around 20 or so.
Seldom my fault.

---

With each crime and every kindness we birth our future.

Thats normal.
Mostly its stock cuda thats missing one signal.
But you could also update to the new revision.

I always have around 20 or so.
Seldom my fault.

Well I havn't had any invalid so far , I just got started back a couple days ago , and still worry that I might not have it set up right yet...

---

I get a fair amount of inconclusives also. But if you examine some of the tasks, you will likely find that many of your wingmates running that task (same data file) get the same thing. I was a little nervous about it too, but I believe that you eventually get credit for this partial work unit. I think those that end in 'error' are the ones to keep minimized or worry about.

---

State: All (760) · In progress (122) · Validation pending (307) · Validation inconclusive (18) · Valid (308) · Invalid (0)

I don't remember having any inconclusive's in the past.
Is this just part of the new Boinc system , maybe a more detailed , closer check on the data ?

On reason that you did not see them in the past was that we did not have the category 'inconclusive'. It is only fairly recently that they have initiated this cagtegory. In the past these were probably just in the Validation Pending and we did not even notice them.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

Just thought I would chip in here.

After reading this Topic I am not too concerned about the reasons for the "validation inconclusive" state but just wondered if anyone can comment on how many tries there are before an abort state is reached.

Looking at the error/total/success tasks (5,10,5) I believe at 6 errors there will be an abort state.

For example, I see in my list this situ.

Regards,

---

Just thought I would chip in here.

After reading this Topic I am not too concerned about the reasons for the "validation inconclusive" state but just wondered if anyone can comment on how many tries there are before an abort state is reached.

Looking at the error/total/success tasks (5,10,5) I believe at 6 errors there will be an abort state.

For example, I see in my list this situ.

Regards,

Your answer is in your pic, ;-)

max # of error/total/success tasks 5, 10, 5

5 errors will abort the workunit but in the case of that workunit unless someone provides a conclusive result within 10 resends or 5 completed tasks it will also abort.

Cheers.

---

Thanks Wiggo for a complete answer to my question.

It did not occur to me to consider resends but all is clearer now.

---

The work unit (WU) validation process takes way too long to resolve, especially for very large WUs. I would suggest a change in the "tie-breaker" logic when determining a winner, at least for very large WUs, for example:



It appears obvious that the second computer either manually flushed this WU or it was nearly instantly aborted during computation (less than 10 CPU seconds) compared to the first computer (19K+ seconds). The delta is vast, and it seems to me the winner is obvious-- no need to wait a week or two for some other machine to crunch for another 19K+ seconds on this WU.

It seems really unfair for the computer that spends such a vast amount of resources on a WU to be held in limbo because another computer dumps it before really doing much work at all.

Moreover, it appears these larger WUs are held in "inconclusive limbo" far more frequently than smaller WUs, probably because so many computers are barfing on these big units early on.

This probably helps explain why many computers are avoiding these larger WUs...

---

"History is a pack of lies about events that never happened told by people who weren't there." - Santayana

The work unit (WU) validation process takes way too long to resolve, especially for very large WUs. I would suggest a change in the "tie-breaker" logic when determining a winner, at least for very large WUs, for example:



It appears obvious that the second computer either manually flushed this WU or it was nearly instantly aborted during computation (less than 10 CPU seconds) compared to the first computer (19K+ seconds). The delta is vast, and it seems to me the winner is obvious-- no need to wait a week or two for some other machine to crunch for another 19K+ seconds on this WU.

It seems really unfair for the computer that spends such a vast amount of resources on a WU to be held in limbo because another computer dumps it before really doing much work at all.

Moreover, it appears these larger WUs are held in "inconclusive limbo" far more frequently than smaller WUs, probably because so many computers are barfing on these big units early on.

This probably helps explain why many computers are avoiding these larger WUs...

While the logic about the second WU beeing the wrong one is valid, what is not valid is to automatically determine that the first should be deemed as valid.
For the accuracy of the science the project requires at least 2 WUs from different users that give the same results as a safety meassure to be sure that the result is correct.

---