Why so many inconclusive's

Message boards : Number crunching : Why so many inconclusive's
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Floyd
Avatar

Send message
Joined: 19 May 11
Posts: 524
Credit: 1,870,625
RAC: 0
United States
Message 1337956 - Posted: 14 Feb 2013, 0:41:11 UTC

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 ?
ID: 1337956 · Report as offensive
Profile Mike Special Project $75 donor
Volunteer tester
Avatar

Send message
Joined: 17 Feb 01
Posts: 33267
Credit: 79,922,639
RAC: 80
Germany
Message 1337957 - Posted: 14 Feb 2013, 0:43:38 UTC

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.
ID: 1337957 · Report as offensive
Profile Floyd
Avatar

Send message
Joined: 19 May 11
Posts: 524
Credit: 1,870,625
RAC: 0
United States
Message 1337958 - Posted: 14 Feb 2013, 0:50:19 UTC - in response to Message 1337957.  

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...
ID: 1337958 · Report as offensive
ExchangeMan
Volunteer tester

Send message
Joined: 9 Jan 00
Posts: 115
Credit: 157,719,104
RAC: 0
United States
Message 1337995 - Posted: 14 Feb 2013, 3:17:52 UTC

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.

ID: 1337995 · Report as offensive
Profile Bill G Special Project $75 donor
Avatar

Send message
Joined: 1 Jun 01
Posts: 1282
Credit: 187,688,550
RAC: 182
United States
Message 1338056 - Posted: 14 Feb 2013, 11:06:14 UTC - in response to Message 1337956.  
Last modified: 14 Feb 2013, 11:06:48 UTC

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
ID: 1338056 · Report as offensive
Profile archeye
Volunteer tester
Avatar

Send message
Joined: 17 Aug 12
Posts: 7
Credit: 699,248
RAC: 0
Austria
Message 1340519 - Posted: 24 Feb 2013, 19:55:19 UTC
Last modified: 24 Feb 2013, 20:02:35 UTC

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,


ID: 1340519 · Report as offensive
Profile Wiggo
Avatar

Send message
Joined: 24 Jan 00
Posts: 26237
Credit: 261,360,520
RAC: 489
Australia
Message 1340542 - Posted: 24 Feb 2013, 20:54:40 UTC - in response to Message 1340519.  
Last modified: 24 Feb 2013, 20:59:13 UTC

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.
ID: 1340542 · Report as offensive
Profile archeye
Volunteer tester
Avatar

Send message
Joined: 17 Aug 12
Posts: 7
Credit: 699,248
RAC: 0
Austria
Message 1340549 - Posted: 24 Feb 2013, 21:21:41 UTC - in response to Message 1340542.  
Last modified: 24 Feb 2013, 21:22:54 UTC

Thanks Wiggo for a complete answer to my question.

It did not occur to me to consider resends but all is clearer now.
ID: 1340549 · Report as offensive
Profile SonicAgamemnon Project Donor
Avatar

Send message
Joined: 8 Apr 06
Posts: 33
Credit: 30,435,904
RAC: 7
United States
Message 1344548 - Posted: 9 Mar 2013, 14:00:53 UTC

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
ID: 1344548 · Report as offensive
Horacio

Send message
Joined: 14 Jan 00
Posts: 536
Credit: 75,967,266
RAC: 0
Argentina
Message 1344552 - Posted: 9 Mar 2013, 14:24:54 UTC - in response to Message 1344548.  

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.
ID: 1344552 · Report as offensive

Message boards : Number crunching : Why so many inconclusive's


 
©2022 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.