Since the other thread was getting rather large, here is a new one.

Pam Heinze

Think of our lost time as "lost in space ha ha ....." could one day those signals get picked up and answered by a AI silicon made person ???

http://setiathome.berkeley.edu/workunit.php?wuid=132971269
http://setiathome.berkeley.edu/workunit.php?wuid=131935857
http://setiathome.berkeley.edu/workunit.php?wuid=131455485

---

Here's a few for me:

http://setiathome.berkeley.edu/result.php?resultid=543106129 cobblestones 15.11

http://setiathome.berkeley.edu/result.php?resultid=543106107 cobblestones 46.13

Total cobblestones lost = 61.24

If they can be added to my total, that would be appreciated.

---

Better check those again, they were hard errors.

Alinator

http://setiathome.berkeley.edu/workunit.php?wuid=129043358

Posted 29 May 2007 7:45:43 UTC
..and nothing happened! :-(

I have a lot of still available 'invalid results'! :-(

Maybe one of the Berkeley-crew could tell us that this thread is considers and the Credits will be given to us or not?!?!

---

Good Afternoon All

I am one of the silly people that look at this and then let Eric know something needs to be done. With events happening to get Servers Up to Peak Performance, the errors you post are Important but have a lower priority.

I will let Eric know someone needs to come and look! So that you know things will not happen instantly. They actually look at the errors which is very time consuming, then like the "fix_missing_results on kosh" things can happen on a broader scale.

I do have to say, that if it really appeared to be an error on your computers side, and you are doing things like overclocking. Then it may not be an error on the Seti side. You can start a thread and ask for someone to take a look and see what they see... They can also offer other advice on how to correct some of those issues.

Thank You All

Pappa

---

Please consider a Donation to the Seti Project.

Maybe it's possible that the 'validate errors' are longer available on the server, that the people (Berkeley- and we) have more time to look to them?

A new one:

http://setiathome.berkeley.edu/workunit.php?wuid=129455860

---

I will let Eric know someone needs to come and look!

i would appriciate that cuz there's definetly somethimg wrong server side.

http://setiathome.berkeley.edu/workunit.php?wuid=135058383
http://setiathome.berkeley.edu/workunit.php?wuid=135058351
http://setiathome.berkeley.edu/workunit.php?wuid=134786441
http://setiathome.berkeley.edu/workunit.php?wuid=134786516
http://setiathome.berkeley.edu/workunit.php?wuid=132410053

---

Join BOINC United now!

i would appriciate that cuz there's definetly somethimg wrong server side.

While SETI@home has had many server-problems, all problems isn't neccessarily server-side, since there's been more than one buggy client, especially among all the clients failing alpha-testing.

One example was some of the v4.5x-builds, there the client happily deleted the result if for any reason didn't suceeded uploaded on 1st. try...

Taking a look back, in December 2006/February 2007 there was multiple reports of some of the v5.7.xx and v5.8.xx-clients showing "socket read uncomplete", or just failing validation. Example from BOINC-forums and SETI beta, and even on BOINC alpha-list. While many of the reports was with SETI@home, there's also reports with other projects.

Especially one of the posts with v5.8.0 is interesting, showing the actual result-file on disk before upload doesn't contain any signals, meaning even if it's uploaded it will always fail validation...

AFAIK there's been no threads reporting similar problems with v5.8.16...

So, it seems there's a good probability there was one or more client-bugs in December/January that screwed-up uploaded results, and this bug was fixed by atleast v5.8.16.


v5.9.0 that seems to be used for a good majority of reported error-results in this thread, is dated January 2007, so my guess is it contains the same bugs as the other BOINC-clients from the same time-period...

---

"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."

Let's keep the difference between a "Validate error" and other validation issues clearly in mind. If the host's core client has uploaded a file and the Validator can find it, the Outcome will not be "Validate error".

If the 5.4x clients which deleted results when upload failed then went on to report those results as if they had been successfully uploaded, that would qualify. But I don't recall that combination.

                                                                 Joe

Let's keep the difference between a "Validate error" and other validation issues clearly in mind. If the host's core client has uploaded a file and the Validator can find it, the Outcome will not be "Validate error".

If the 5.4x clients which deleted results when upload failed then went on to report those results as if they had been successfully uploaded, that would qualify. But I don't recall that combination.

                                                                 Joe

I'm not following you two enough because of not knowing the back end stuff enough....but here's something to ponder over:

I went ahead and stopped using 5.5.0 that reported immediately. Since installing 5.8.16, I have not had a single validate error. Is this coincidence? I'm thinking "maybe", because along with the CC change, the back end has been able to talk better to its' various internal processes...

Brian

Let's keep the difference between a "Validate error" and other validation issues clearly in mind. If the host's core client has uploaded a file and the Validator can find it, the Outcome will not be "Validate error".

If the 5.4x clients which deleted results when upload failed then went on to report those results as if they had been successfully uploaded, that would qualify. But I don't recall that combination.

It's a very long time since 2004 and v4.5x, so I don't remember if it reported as error or not.


As for "Validate error", the SAH-validator specifically mentions "read and parse the result file", and in case of error it's logged as "read/parse of #s FAILED with retval...", before result is marked as error.

So maybe I'm mis-understanding something here, afterall I'm fairly blank then it comes to SETI@home, but for me it looks like a result-file without any signals in it will be marked as "Validate error"...

---

"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."

Let's keep the difference between a "Validate error" and other validation issues clearly in mind. If the host's core client has uploaded a file and the Validator can find it, the Outcome will not be "Validate error".

If the 5.4x clients which deleted results when upload failed then went on to report those results as if they had been successfully uploaded, that would qualify. But I don't recall that combination.

It's a very long time since 2004 and v4.5x, so I don't remember if it reported as error or not.


As for "Validate error", the SAH-validator specifically mentions "read and parse the result file", and in case of error it's logged as "read/parse of #s FAILED with retval...", before result is marked as error.

So maybe I'm mis-understanding something here, afterall I'm fairly blank then it comes to SETI@home, but for me it looks like a result-file without any signals in it will be marked as "Validate error"...

You just didn't chase it back far enough. That possible parse error comes from trying to find out what the path to the result file is. If the path is found and the result successfully opened, retval is zero and there cannot be a Validate error.

Parsing for signals is later, and divided by signal type. Because it is common for there to be no signals for a particular type, having none at all would cause no difficulty. In any case, that 5.8.0 case of no signals in the result file was simply an instance of the size mismatch error which caused upload to fail, backoff, rinse and repeat forever until the user aborted the transfer. Richard Haselgrove diagnosed the problem as BOINC restarting a completed WU if another completed about simultaneously.

                                                                Joe

http://setiathome.berkeley.edu/workunit.php?wuid=131907974

---

http://setiathome.berkeley.edu/workunit.php?wuid=135029774
http://setiathome.berkeley.edu/workunit.php?wuid=131455485
http://setiathome.berkeley.edu/workunit.php?wuid=133311811

---

http://setiathome.berkeley.edu/workunit.php?wuid=134233285

---

I'm now getting mad about that one here.
http://setiathome.berkeley.edu/workunit.php?wuid=129399691

Could sombody please explain to me, why i get an validate error there ?

While looking at the first reported result i see a "Checked, but no consensus yet"
That's ok with me, but should the validator wait for the third result before rejecting mine ?

hmmm...

---

Join BOINC United now!

I'm now getting mad about that one here.
http://setiathome.berkeley.edu/workunit.php?wuid=129399691

Could sombody please explain to me, why i get an validate error there ?

While looking at the first reported result i see a "Checked, but no consensus yet"
That's ok with me, but should the validator wait for the third result before rejecting mine ?

hmmm...

Is that one of your CCs (5.10.0)? If so, is it reporting immediately? If so, bear in mind that I was still using your 5.5.0 when I was seeing validate errors. Since going to 5.8.16, I have not had any validate errors.

Brian

I'm now getting mad about that one here.
http://setiathome.berkeley.edu/workunit.php?wuid=129399691

Could sombody please explain to me, why i get an validate error there ?

While looking at the first reported result i see a "Checked, but no consensus yet"
That's ok with me, but should the validator wait for the third result before rejecting mine ?

hmmm...

Is that one of your CCs (5.10.0)? If so, is it reporting immediately? If so, bear in mind that I was still using your 5.5.0 when I was seeing validate errors. Since going to 5.8.16, I have not had any validate errors.

Brian

No, stock source (5.10.0) and No mods at all. IMHO there's something wrong with the validator and the reason for that is NOT the user side, nor what boinc client is beeing used.

---

Join BOINC United now!

Almost same prob here, tons of validate errors, using Crunch3r core Version 5.9.0.32
[added later] and Ckicken optimized app 2.2B [/end added later]

Here are some

http://setiweb.ssl.berkeley.edu/result.php?resultid=553961542
http://setiweb.ssl.berkeley.edu/result.php?resultid=553961532
http://setiweb.ssl.berkeley.edu/result.php?resultid=553961522
http://setiweb.ssl.berkeley.edu/result.php?resultid=549922416
http://setiweb.ssl.berkeley.edu/result.php?resultid=548975047
http://setiweb.ssl.berkeley.edu/result.php?resultid=548974975
http://setiweb.ssl.berkeley.edu/result.php?resultid=548974783
http://setiweb.ssl.berkeley.edu/result.php?resultid=542912884

and many more, better not to make the complete list.

Any idea some1 ? Is it possbile that all WU are in some way "orphaned" (meaning without any known reference) on the validator ?


Thanks
M.

---