Ill appologise if there is already a thread on board for this problem but how come some of my results i have uploaded and are succesful along with 2 other succesfull uploads from other users all 3 of us have recieved 0.00 credits ?

application SETI@home
created 28 Aug 2004 6:23:35 UTC
name 25ap04aa.23553.18208.803406.122
granted credit 0.00

is but one example any ideas plz.

Thnx in advance.

---

> Ill appologise if there is already a thread on board for this problem but how
> come some of my results i have uploaded and are succesful along with 2 other
> succesfull uploads from other users all 3 of us have recieved 0.00 credits ?
>
> application SETI@home
> created 28 Aug 2004 6:23:35 UTC
> name 25ap04aa.23553.18208.803406.122
> granted credit 0.00
>
> is but one example any ideas plz.
>
> Thnx in advance.
>

In the result id you will see Validate state - Check skipped. This can happen when there are a lot of invalid returns for a work unit even though there were 3 success done results.

Edit: Check this link posted by Paul D. Buck in another thread -

Workunit and Result State Transitions

It can be a little difficult to read but shows various ways a wu is handled by the validator.

Spot on yer seems to be skipped . . . Bit unfair as 3 people still returned successfull results but still not to worry as it seems all is working fine now 4.13 as solved all my problems i was having apart from the slower process time.

Played Seti & Boinc things are finally looking improved.

---

Kathless,

If you can give a link to the WU we can do more...

But, the transitions as "BOINC User" has pointed you to does explain it (in computerese). The most likely explanation is that the results do not agree with each other. In that case, no credit will be given.

Other cases, the work unit is "successful" but the lowest credit claimed is 0, so you get 0 ...

It is still my belief that there are still "issues" with the credit claim/grant process but we have been struggling with so many other issues that are more immediate that these have been "hidden" in the swamp of other things to fix.

When I look at my history of Results I see many still in "Pending", some with 0 granted, some errored out, etc. that I am a little concerned. However, as I said, the whole process was under such a strain and the back-log so large that it is only now that these "new" problems can be seen.

---

> Kathless,
>
> If you can give a link to the WU we can do more...
>

Paul,

Work Unit 1498053

I was sure to look at the wu before posting this time. ; )

Please look at it because there may be other reasons for the 0 credit.

Like you and others; I have pending that may never receive credit and have to live with.

---

Paul,

I have quit a few of the still pending status that have also received 3 successful results but no credit was issued. I personally think that it may be due to some of the software/hardware problems that we have experienced and most likely will never see these credits issued. Here are a few example's to look over:

Work Unit 8632
Work Unit 1235877
Work Unit 1310496

---

----------<br>
<img src=\"http://boinc.mundayweb.com/seti2/stats.php?userID=924&amp;trans=off\"><br>
<a href=\"http://setiweb.ssl.berkeley.edu/team_join_form.php?id=30199\">Join</a> the <a href=\"http://ocforums.com\">Overclockers.com</a> SETI Team!

> Work Unit
> 1498053
>
> I was sure to look at the wu before posting this time. ; )
>
> Please look at it because there may be other reasons for the 0 credit.
>
> Like you and others; I have pending that may never receive credit and have to
> live with.

I cannot see any reason ... :(

Worse, I looked in the documentation and can find no explanation for the check skipped.

However, If I have the sense of the Transitioner code (always doubtful as I have a hard time with the C Language), the problem is that the "Couldn't validate" returned "blew-up" the work unit for everyone. So, that error, invalidated the WU and they system wrapped them up with a bow ribbon, stuck the fork in it, we are done ...

If anyone that can read C wants to check my work, look for this VALIDATE_STATE_NO_CHECK in the source code (transitioner.C is the file that seems to cook our goose).

Anyway, that is the best I can come up with right now ... sorry I cannot say for sure ...

---

Texasfit,

A quich look at these:

> Work Unit
> 8632
> Work Unit
> 1235877
> Work Unit
> 1310496

I think you are ok, you just have not yet seen a quorum of results yet. So, for the moment I think you are ok...

Just remember, I am just a participant like you and have no "magic" (I wish I did) so ... don't give up yet, I think these are just waiting for the quorum to form and it has not yet. Or the transitioner and validator have not gotten to them yet (for wahtever reason) ...

---

> Texasfit,
>
> A quich look at these:
>
> I think you are ok, you just have not yet seen a quorum of results yet. So,
> for the moment I think you are ok...
>
> Just remember, I am just a participant like you and have no "magic" (I wish I
> did) so ... don't give up yet, I think these are just waiting for the quorum
> to form and it has not yet. Or the transitioner and validator have not gotten
> to them yet (for wahtever reason) ...
>

Since these are so old, I was thinking that they may just be with ET somewhere. :-) I have a few of these that I am going to monitor for a while, just for my own curious self.

With this work unit, why is one computer granted 0 credit, but the others granted 36.82? The computer that is granted 0 completed the work successfully?

Work Unit 2628599

maybe it come from the operation system
this with 0 garanted is linux
the 2 anothers windows 98
----------------------------
for few weeks i read its different,what send back to server

---

BUMP ruleZ

> maybe it come from the operation system
> this with 0 garanted is linux
> the 2 anothers windows 98
> ----------------------------
> for few weeks i read its different,what send back to server

Hmmm, but as far as I know, three same results is a quorum, therefore the win98 and linux results must have been the same, since the credit was granted for the unit (except to one host).

Could be just a bug on the web page...

> > maybe it come from the operation system
> > this with 0 garanted is linux
> > the 2 anothers windows 98
> > ----------------------------
> > for few weeks i read its different,what send back to server
>
> Hmmm, but as far as I know, three same results is a quorum, therefore the
> win98 and linux results must have been the same, since the credit was granted
> for the unit (except to one host).
>
> Could be just a bug on the web page...
>
>
That 00 result shows that it could not be validated.
Validate state = Invalid

I had some of those zero credit WU's but others got credit, even though all were successful. I believe the consensus is that my computer made a calculation error and the "checksum" didn't compare with the other results (for the same WU). I don't know if checksum is correct here, but the concept is can be used as an example of why a WU can be labeled "invalid".

Several things come to mind that could cause calculation errors such as memory problems, over heated processor, etc. I guess even the transmission of the WU could cause a loss of data. Then there could be problems on the Berkeley end. Lot's of stuff that could go wrong.

Now Paul's going to yell at me for not reading the documentation!

> I had some of those zero credit WU's but others got credit, even though all
> were successful. I believe the consensus is that my computer made a
> calculation error and the "checksum" didn't compare with the other results
> (for the same WU). I don't know if checksum is correct here, but the concept
> is can be used as an example of why a WU can be labeled "invalid".

OK, but what I don't understand is that how could there have been a quorum if only two results were valid?

---

> OK, but what I don't understand is that how could there have been a quorum if
> only two results were valid?
>


There are two values I think are causing some confusion. See Workunits.

min_quorum = The minimum size of a quorum. Set this to two or more if you want redundant computing.

target_nresults = How many successful results to get. This must be at least min_quorum. It may be more to reflect the ratio of result loss, or to get a quorum more quickly.

We will have to hear from an admin to be sure but I think the min_quorum value is 2 and the target_nresults value is 3.

I believe the target_nresults determines when the results are sent to the validator. It only takes 2 valid results, the min_quorum, to get credit.

Valid is different from successful.

---

> We will have to hear from an admin to be sure but I think the min_quorum value
> is 2 and the target_nresults value is 3.

Ahhh, I see, thanks.

---

Hi!

I had a look into the source code to finger out, where the 0.00 credit grants came from. To continue, I'm in need of the project specific functions check_set and check_pair, which are used in validator.C.
Any idea, where I can find the files containing this code?

Geetings to the project crew!

---

> Now Paul's going to yell at me for not reading the documentation!

I don't yell ... :)

And it is a free world, well, mostly ...

And the results comparison for SETI@Home does not look at a checksum. Rather it looks at the data sent back. For example, if you send back the fact that you found 3 spikes and 2 Gaussians and all other results have 4 spikes and 3 Gaussians, wel, you don't compare.

I believe they also do tests of the power levels too ...

---

Hi once again!

I've looked through the boinc part of the validation an transistion code. It looks good in my eyes. From the point, where credit generation is taken over from the project dependent (seti) code, to the point of granting everyting seems to be fine and is written in clear and easy to understanding code. Compliments to the author.

So I assume, the granting of 0.00 credits for sucessfull validated work might be caused by the seti part of the validator.
Cause I havn't seen the code, I have to guess, what the problem might be:
First idea is a missing check for the unit result state, where the amount of granted credits is computed. It seems the second lowest value of pending claimed credits is token, regardless of the client result state. Maybe only a check is missing.

Geetings to the project crew ... and everyone here!

---