I can't even count the WU's i've crunched with a valid return that now are granted 0 credits as one cruncher has the "upload error" with 4.09...

Seems there was valid work done, and valid work return, but now the validator status is "Check Skipped"..

Will the WU be re-issued? Bet not!

Seems the "other two" crunchers will get no credit due to a server error. I've lost 100's of credits due to the fact that another user encountered a server bug!

That just doesn't seem right....

---

Or, more to the point... lots of potentially valuable scientific work will be lost if this is true.

---

> Or, more to the point... lots of potentially valuable scientific work will be
> lost if this is true.
>
E.g. some valid ET signal here and there...

I think it should be really simple to re-issue such WUs.

Peter

> I can't even count the WU's i've crunched with a valid return that now are
> granted 0 credits as one cruncher has the "upload error" with 4.09...
>
> Seems there was valid work done, and valid work return, but now the validator
> status is "Check Skipped"..
>
> Will the WU be re-issued? Bet not!
>
> Seems the "other two" crunchers will get no credit due to a server error.
> I've lost 100's of credits due to the fact that another user encountered a
> server bug!
>
> That just doesn't seem right....
>

you don't get a "Check Skipped" due to an upload error. It results from returned results count max limit being exceeded without getting a tripple valid match.

The upload error is treated just like any other error - download error, invalid, compute error, etc. - in reaching this max limit.

Based on what I have seen, this max limit is set at 8.

regards
Z

---

<img src="http://www.boincstats.com/stats/banner.php?cpid=e16795c0df46cd9701574ad087f14cf9">

>
> you don't get a "Check Skipped" due to an upload error. It results from
> returned results count max limit being exceeded without getting a tripple
> valid match.
>
> The upload error is treated just like any other error - download error,
> invalid, compute error, etc. - in reaching this max limit.
>
> Based on what I have seen, this max limit is set at 8.
>
> regards
> Z
>
Isn't that what azwoody is saying? If 6 user's sent in a WU that had upload errors and then two successfully sent in the same WU, they (the last two) wouldn't get credit because it would be marked "Check Skipped".

> >
> > you don't get a "Check Skipped" due to an upload error. It results from
> > returned results count max limit being exceeded without getting a
> tripple
> > valid match.
> >
> > The upload error is treated just like any other error - download error,
> > invalid, compute error, etc. - in reaching this max limit.
> >
> > Based on what I have seen, this max limit is set at 8.
> >
> > regards
> > Z
> >
> Isn't that what azwoody is saying? If 6 user's sent in a WU that had upload
> errors and then two successfully sent in the same WU, they (the last two)
> wouldn't get credit because it would be marked "Check Skipped".
>

if I read azwoody's post correctly it stated that

one upload error result will cause a "Check Skipped" situation in 2 valid results even if there are just 3 results in total.

regards
Z

---

<img src="http://www.boincstats.com/stats/banner.php?cpid=e16795c0df46cd9701574ad087f14cf9">

> one upload error result will cause a "Check Skipped" situation in 2 valid
> results even if there are just 3 results in total.
>
> regards
> Z
>

And what I'm seeing now, is that since the validator got a "check skipped" from another user, my valid result got eaten by "the file deleter", and although the work is being re-issued, I'll never see credit - All my WU which were ok a couple days back, now have the "missing file" status as soon as a re-issued result comes back and the validator makes a pass....

There's no doubt that seti/boinc tossed a bunch of valid results here! But hey, it's not really new science anyway, as we're still doing the same science on the same WU's that have been done by Seti Classic! (be it much slower with 4.05! Glad I'm on LINUX for seti/boinc!), so why worry? Only that LHC or CP could have made use of those lost cycles!

---

azwoody,

I'm seeing the same thing on a number of my results.

>
> And what I'm seeing now, is that since the validator got a "check skipped"
> from another user, my valid result got eaten by "the file deleter", and
> although the work is being re-issued, I'll never see credit - All my WU which
> were ok a couple days back, now have the "missing file" status as soon as a
> re-issued result comes back and the validator makes a pass....
>

I'll repost my message from another thread:

I have one WU that has been in "pending" status since 2 September. The first result returned has a zero CPU time, so we won't get credit for it anyway. Yet, two of us returned CPU times much greater than zero, about 3.5 hours for one and about 6 hours for the other. The WU still seems be "stuck" in "pending."

Then, I have a number of WU's where a quorum has (supposedly) been reached, each computer achieving a "Over-Successful-Done" status has claimed some credit, yet the amount of credit granted to the three of us is zero. For example, WU:
http://setiweb.ssl.berkeley.edu/workunit.php?wuid=1160818
The low clamed credit is 30.39, the high is 60.57, the middle is 46.44, yet we get zero. If these are "bad" WU's or there is some error in computation, why hasn't the result status for the WU been changed from "Success" to some error status?

[EDIT] Okay, I found out part of the problem with the example WU, the three supposedly "valid" WU's have a "Validate state" of "Check skipped." There is one result with a "Over-Client error-Computing" status, two with a "Over-Unknown-New" status, and two with a "Over-No reply-New" status. There were three apparently valid results returned, but they apparently didn't get validated because they have the "Check skipped" "Validate state" set. Over eight hours of processing pissed away, and the returned results probably won't be used!![/EDIT]

I would like to see a response to this situation from one (or more) of the Admins. There does seem to be an error in either the result validation/status setting or the credit reporting portion of the system. I understand there are more important things in the work queue than this, but I would still like to see some response to this matter.

Cheers,

Stephen

---

<P>"I want to go dancing on the moon, I want to frolic in zero gravity!....", and now, I might be able to go someday! Thanks, SpaceShipOne and crew!<BR><a><img src="http://69.93.59.107/stats/banner.php?cpid=26cbd89db7fb85cbfe580729d76705c1"></a>

>... Only that LHC or CP could have made use of those lost cycles!


LHC already had the same problem with some results.

CPDN cannot have this problem as they do not cross-check results.
_______

Question on the http://setiweb.ssl.berkeley.edu/workunit.php?wuid=1160818 example is :

Why did they send them out again on 9 Sep - at that point it must already have been clear that too many errors existed.

I have no idea why SETI does, or does not, do many things.

However, I feel the two "Over-No reply-New" results should not be counted as "real" errors since they were probably the results of people resetting the project, the expiration date passing, and the "Validate state - Check skipped" status being set, possibly because there was already a quorum.

The "Over-Client error-Computing" result may not have been a "real" error, although its stderr.txt speaks of an "unhandled exception" and says something about a "delay load helper". I have no idea to what they refer.

I once received an "Over-Client error-Computing" error status because I attempted to display the graphics display (in CC 4.06, I think) and the science client crashed. I never try to display the graphics, now. I was within minutes of finishing with that WU, too.

They don't list explainations for all of the status states that are displayed.

I have absolutely no idea when they sent them out again. I processed one of those 9 Sep WU's. I returned apparently good results, but I also got a "Validate state - Check skipped" status, and no credit for over 5.5 hours of computation (60.57 credits requested.)

>
> Question on the http://setiweb.ssl.berkeley.edu/workunit.php?wuid=1160818
> example is :
>
> Why did they send them out again on 9 Sep - at that point it must already have
> been clear that too many errors existed.
>

Cheers,

Stephen
S@h Berkeley's Staff Friends Club © Member

---

<P>"I want to go dancing on the moon, I want to frolic in zero gravity!....", and now, I might be able to go someday! Thanks, SpaceShipOne and crew!<BR><a><img src="http://69.93.59.107/stats/banner.php?cpid=26cbd89db7fb85cbfe580729d76705c1"></a>

I posted this in another thread but it may apply here, also. Just my opinion on another possibility.

I think that many of us have this same or similar situations with credits. I believe that many of these credits were lost due to the problems we were having during the July/August time period and having to roll back the DB. The validator was behind and off much of the July/August time periods and then they had the DB problems. The quote below explains some of this issue and may be part or all of the problem with getting credits on these wu's. Not all of mine but some do show a message that leads me to believe this work was and is lost forever. Many of these were sent back out but some were not as mentioned on one of our news updates. Message shows:

core_client_version-3.20
file transfer error: couldn't get input files:
25ap04aa.23553.12722.167344.52: file was not found on server

Error Result above

Never was sent back out but was in this time period

3 good results still pending

[b]August 25, 2004
A trio of splitters are now up and producing new work.
We plan to release major version 4 of BOINC and SETI@Home tomorrow.
A clarification about last week's fallback to an earlier DB state: all work that was uploaded during the period of August 13th to 18th was lost and so cannot be credited. As well, all work that was generated and downloaded during that period was lost to the DB and so cannot be credited. This work is being regenerated and redistributed.</B>

---

----------<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!