why no credit??
17 Apr 2006 3:44:51 UTC
Topic 191093
(moderation:
i know that credit doesn't really mean anything but i was wondering why the other 2 people were granted credit while i got nothing?
http://einsteinathome.org/workunit/6968992
why no credit??
)
Akma, as I understand the process of validation, it takes 3 'successful' returns of a WU to form a quorum but if your result is beyond an error tolerance when compared to the other two successful results, you receive zero credit. The BOINC WIKI probably has better explanation...Rog. Sorry:(.
Here is a simple
)
Here is a simple explanation:
Each host calculates the cosinus value of the input data in different ways.
You can see that each host has an error, but the host-1 gives back the most precise value.
Moreover, host-1 did an invalid result!
I hope you can understand the reason if you have a look at this table.
The validator doesn't know which value is the best, it does just a comparison.
RE: You can see that each
)
Brilliant! I understood that! :-)
There is an old mariner's saying:
'When going to sea,
take one clock or three ....'
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Each host calculates
)
Where do these differences come from?
Your optimised apps?
Or is it something cpu-specific?
RE: RE: Each host
)
I hope you know it was just an example.
Einstein@Home does a bit more than a simple cosinus calculation.
I hope nobody confuses it...
There are no differences if everybody runs the same executables, but of course it doesn't mean that the result is precise. It means just there are no differences between results.
I changed the executable code, so it's a good reason of it.
Usually all processors have IEEE754 compatible operation units, so the generation of same result is possible, but sometimes the different platforms needs different compilers. And the different compilers sometimes compile different executables. And it is a good reason to...
From reading this and
)
From reading this and something I read in the Wiki Validation process, is there enough evidence to say that the validation process always chooses the correct result(s).
I must admit I am sometimes sceptical when the odd result I do is pronounced invalid, and on checking find that the other two or three were done on different types of cpu and/or OS. Of course it is so infrequent I do not have an invalid result in my account at the moment so cannot give an example.
Andy
A very long time ago, Paul
)
A very long time ago, Paul Buck lead a discussion of this topic (in which I participated) on the SETI forum. In that discussion, it was noted that one result must be set as the canonical result to which others are compared (i.e., that is where the errors produced by rounding, etc. are defined). In that long ago discussion, the topic centered around the order of return and the likelihood of the result being invalid. The argument settled on the possibility (or probability) that the third result is always more likely to receive an invalid designation because the validation error bound appears to be decided by the first two results (at least on SETI).
This may be relevant here given that, IIRC, akosf's optimizations can (or do) affect the precision level of the result. I wonder if anyone has noticed that their invalid results tend to be the last returned?
RE: I wonder if anyone
)
>Interesting point, Scott......Akma's failed result WAS the last return....maybe a convincing case for a small cache and fast return of WUs?....Cheers, Rog.
RE: RE: I wonder if
)
I think my results are almost always the last ones, because I have a big cache.
And I must have a big cache because the WUs are not long enough.
So this situation is not solvable for me.
cu,
Michael
RE: This may be relevant
)
My last 3 zero Results was
1. Result
http://einsteinathome.org/workunit/7018545
1. Result
http://einsteinathome.org/workunit/6864194
3. Result
http://einsteinathome.org/workunit/6947928
Chris
*Die Signatur befindet sich aus technischen Gründen auf der Rückseite dieses Beitrages!*