granted credit zero
26 Feb 2005 17:29:18 UTC
Topic 188052
(moderation:
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 ?
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
> When you click on the
)
> 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
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.
> but why Outcome=Success, i
)
> 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
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 ...
> 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 ...
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
> > Isn't it strange that the
)
> > 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 ?
I noticed that the machine
)
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?
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 ?
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
