Well thought i had seen it all ??
Zero credit granted for a WU, caused by too many succes results ?

http://setiweb.ssl.berkeley.edu/workunit.php?wuid=11196405

Just wanted to share this

Bukken

Keep Crunching

---

That one will miff a few. Credit should be granted.

We should start a campaign "No Credit, No Crunch" !

---

> That one will miff a few. Credit should be granted.
>
> We should start a campaign "No Credit, No Crunch" !
>
Tony: "yeah.. chanting, NO Credit, No Crunch.....No credit, No crunch..... No credit, no Crunch"

Forum user: "tony, what's that crunching noise in the background?"

Tony: "Ummmm.. Errrrr... Never mind.. got to go, bye"

> Well thought i had seen it all ??
> Zero credit granted for a WU, caused by too many succes results ?
>
> http://setiweb.ssl.berkeley.edu/workunit.php?wuid=11196405
>
> Just wanted to share this
>
> Bukken
>

Dang! That really bites. I had a unit that got zero credit because i was the ONLY one to crunch it successfully, i had no idea you could lose credit if too MANY people were successful.

Yikes!

Dig

---

> Well thought i had seen it all ??
> Zero credit granted for a WU, caused by too many succes results ?
>
> http://setiweb.ssl.berkeley.edu/workunit.php?wuid=11196405
>
> Just wanted to share this
>
> Bukken
>
> Keep Crunching
=========================
Looking at the result ID's for the completed ones they all say workunit error - check skipped.

---

This sort of WU represents much less than 1% of the 158 results of my study. In fact, there was only one like occurrence. this one however WAS granted credit. WU ID 8229712. In 99% of the time ONE wu is issued each time a result gets back ONE error. This one like the one on this thread however reissued it two more times than I think it should have.

In other words, both should have validate with the sixth issue, the 7th and 8th appear to be unnecessary. it might be something in the Validator software.

In any case, it doesn't happen often enough to be a big deal.

(2 cents inserted)

tony

---

Problem was each WU was, Validate state Workunit error - check skipped



stderr out 4.19





Validate state Workunit error - check skipped
Claimed credit 43.6372467879204
Granted credit 0
application version 4.09

---

Semper Eadem
So long Paul, it has been a hell of a ride.

Park your ego's, fire up the computers, Science YES, Credits No.

> Well thought i had seen it all ??
> Zero credit granted for a WU, caused by too many succes results ?
>
> http://setiweb.ssl.berkeley.edu/workunit.php?wuid=11196405
>
> Just wanted to share this
>

6 computers managed calculating 6 different answers, and the validator didn't manage finding a pair of results to be "similar enough". Since getting different answers every time can be due to buggy application or something in the wu, instead of trying an unlimited number of times the wu errored out instead.
Also, it's not certain the disrepancies is due to application/wu, it can be due to hardware-problems or cheaters or buggy OS or something.

Anyway, these wu seems to be few and far between, it's much bigger chance for getting zero credit due to other reasons.

Maybe the wu contains what we've all been looking for and the validator has fallen over with shock?

> This sort of WU represents much less than 1% of the 158 results of my study.
> In fact, there was only one like occurrence. this one however WAS granted
> credit. WU ID 8229712.
> In 99% of the time ONE wu is issued each time a result gets back ONE error.
> This one like the one on this thread however reissued it two more times than I
> think it should have.

Going by the avarded credit, 6 results was used when deciding the crediting, meaning needed all results to validate the wu.

The 7th issue didn't get any credit since was returned after his deadline, and after all other results accounted for.

>
> In other words, both should have validate with the sixth issue, the 7th and
> 8th appear to be unnecessary. it might be something in the Validator
> software.

If only 6 issues had been enough, the 7th would never have been issued. Also, the 8th was only issued due to 7th didn't return before his deadline.

> If only 6 issues had been enough, the 7th would never have been issued. Also,
> the 8th was only issued due to 7th didn't return before his deadline.
>
From looking at my results(my little study) it seemed that 4 successfully reported WUs (near same time anyway, and claimed credit)generally are enough to validate. I can't know what was really reported though. this is why I said "I can't understand why there was a 7th and 8th, it's also the reason it's strange.

The 7th WU reported back on 11 Mar 2005 17:58:56 UTC, but the 8th Wu was issued on 8 Mar 2005 1:18:28 UTC, so the 8th doesn't appear to have been triggered by the failure of the 7th..... Oh wait a minute, I see it, the 7th reported back late, but was still granted "over- success-done" status instead of "Over-no reply-new" as I would have suspected, So the 7ths' lateness caused the issuance of the 8th.

But again, why was there a need for either, or atleast any more?

thanks
tony

Anyway the reason for my previous post was to show they were statistical freaks and should be a cause for concern

> From looking at my results(my little study) it seemed that 4 successfully
> reported WUs (near same time anyway, and claimed credit)generally are enough
> to validate. I can't know what was really reported though. this is why I
> said "I can't understand why there was a 7th and 8th, it's also the reason
> it's strange.

You needs 3 "success"-results before validation is tried, and the validator doesn't care whatever cpu-time and claimed credit are when it comes to validating a result or not.

>
> But again, why was there a need for either, or atleast any more?
>

For some reason 5 different computers managed producing 5 results so differently from eachother they didn't pass validation, and therefore a 6th result was sent out to try getting the wu validated.

This old example shows how it's possible 3 results fails validation while 4 passes validation, and is easily expanded to 4 failing/5 validated.
Since the seti-validator doesn't work exactly like this example-validator, 5 failing/6 validated is also possible. ;)

> > But again, why was there a need for either, or atleast any more?
> >
>
> For some reason 5 different computers managed producing 5 results so
> differently from eachother they didn't pass validation, and therefore a 6th
> result was sent out to try getting the wu validated.

Now I don't understand the validation anymore. From what you're saying I'd guess that validator is doing something like this:

- take 2 results and compare. If they are off by more than 1% (or whatever particular margin is), saj by 1.1%, it's not OK.
- take the third one, compare it to the first one. Say it's off by 0.6%, then it's OK.
- take the second one and compare it to either (first and third). If it's off by less than 1% from either of them (in this case it'd be something like 0.5% off from the third), then it's OK.

Is this it?

My initial guess was that the vaildator only OKs results which are not more than whatever margin is apart and any results that fall in between. On the second thaught you can't really say which group of results is more correct if you have some even distribution of errors ...

---

Metod ...