granted credit zero

debugas
debugas
Joined: 11 Nov 04
Posts: 170
Credit: 77,331
RAC: 0
Topic 188052

here is an example i don't quite understand
four people worked on the WU but the one who claimed least credit actually was granted zero

Is it normal and if not - what went wrong?
why Outcome=Success when result's validate state is Invalid ?

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,851
Credit: 182,906,208
RAC: 37,996

granted credit zero

When you click on the Result that was granted 0.00 credit you'll see that the "Validate state" is "invalid". Something's wron with the output file that was poduced.

BM

BM

debugas
debugas
Joined: 11 Nov 04
Posts: 170
Credit: 77,331
RAC: 0

> When you click on the

Message 5553 in response to message 5552

> When you click on the Result that was granted 0.00 credit you'll see that the
> "Validate state" is "invalid". Something's wron with the output file that was
> poduced.

but why Outcome=Success, i thought outcome would not be success in such situations

gravitysmith
gravitysmith
Joined: 8 Nov 04
Posts: 55
Credit: 67,291,906
RAC: 13,730

Here is another WU (327852)

Here is another WU (327852) with a similar issue. Could it be that the "canonical" result is actually invalid and therefore trashing everybody else's credits? My host (1597) doesn't seem to indicate any errors, and the byte count is identical to the other hosts which received 0 credits.

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,851
Credit: 182,906,208
RAC: 37,996

> but why Outcome=Success, i

Message 5555 in response to message 5553

> but why Outcome=Success, i thought outcome would not be success in such situations

Outcome=success means that the program (Application) ran without crashing. It doesn't tell anything about the result file itself, that's the part of the validator on the server side.

We get a lot of Results back that are more or less numerical garbage, possibly due to overclocking affecting the FPU, though the program didn't really crash.

I currently can't say what's wrong with your particular Result, if it was related to the problem in the validator it should not happen again.

BM

BM

Magnus Back
Magnus Back
Joined: 19 Feb 05
Posts: 12
Credit: 10,964
RAC: 0

Isn't it strange that the

Isn't it strange that the einstein@home WUs return bad results from machines
where seti@home WUs doesn't ...

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,851
Credit: 182,906,208
RAC: 37,996

> Isn't it strange that the

Message 5557 in response to message 5556

> Isn't it strange that the einstein@home WUs return bad results from machines where seti@home WUs doesn't ...

I don't know the SETI code neither of the App nor the validator, but I can imagine at least two reasons for this:

1. SETIs validator isn't as picky as Einsteins. Thus they get back bad results, but don't recognize it at least on the level of analysis the users come to see.

2. SETIs App might rely more on memory and integer operations, while Einstein is definetly FPU bound. The CPU chip gets hot at the spot where the most energy is needed. When it gets too hot, it first breaks the results of the unit that is located there. If an integer unit gives false results, this will soon end in a crash of the program or the OS, e.g. because of wrong memory address calculations. If it's the FPU that gets too hot, you will notice nothing of it while the program runs until you take a close look at the results.

Carl Cristensen told me that CPDN gets all kinds of weird and obviously wrong results from overclocked machines. However I don't know how the CPDN validator handles them.

BM

BM

debugas
debugas
Joined: 11 Nov 04
Posts: 170
Credit: 77,331
RAC: 0

> > Isn't it strange that the

Message 5558 in response to message 5557

> > Isn't it strange that the einstein@home WUs return bad results from
I can imagine one more reason - i work on the PC E@H is running and sometimes my PC hangs up or crashes. I am forced to turn it off and on again and then scan disk finds FAT allocation problems and fixes them. Maybe after such restart E@H faces some problems ?

Molgo
Molgo
Joined: 24 Feb 05
Posts: 1
Credit: 294,539
RAC: 0

I noticed that the machine

Message 5559 in response to message 5557

I noticed that the machine failing to deliver a valid result is a Linux 2.6.10 - machine, while all other machines completing the same WU are on Windows. My own machine (AMD-Duron 1800MHz) is running on Linux 2.6.3-7mdk, and is not overclocked. The first result was marked valid, but the last two, or rather three, results show errors in the log and were marked invalid.

Could this problem be somehow related to stopping/resuming work on a Linux-machine?

The error shown in the log

APP DEBUG: Application caught signal 2
Resuming computation at 23563/2690776/2691132

is I guess due to a shutdown of the program via Ctrl-C in a console. At least this is how I do it, and I get the same errors in my logs.

Any comments?

wijata.com
wijata.com
Joined: 11 Feb 05
Posts: 113
Credit: 25,495,895
RAC: 0

Yhis may be. I just started

Yhis may be. I just started participating to E@H and have few linux machines. Machines send some results, claimed some credits. Every machine which has stopped boinc and run again has been granted zero credits for its work.

Well, in my case I did it for purpose. I find cpu unused becouse client couldn't contact with server to get more work. And
I find in log: Deferring communication with project for 20 hours ....
so i stopped boinc, removed the min_rpc_time line from config
and run boinc again. Now client didn't wait, just contacted server, got some work, and run core. The drawback is that I was grated zero credits.

On one hand I don't like boinc waiting over 20 hours while doing nothing, on the other, I don't want to be granted zero credits.
Any idea how to resolve the case ?

Ned
Ned
Joined: 22 Jan 05
Posts: 18
Credit: 16,396,881
RAC: 7,456

My one and only Linux result

My one and only Linux result suffered the same "invalid" fate with the "zero" credit rating... I had stopped Boinc a few times to see what was happening and to drop out of "X" to console mode.

So, is this a bug in the validator or is the Client not handling the shutdown properly in order the be restarted? Either way, it is a waste of several hours of processing if you expect every WU to have uninterrupted time.

Ol' Retired IT Geezer

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.