Message boards :
Number crunching :
granting less credit than claimed?
Message board moderation
Author | Message |
---|---|
Send message Joined: 6 Feb 08 Posts: 2 Credit: 5,575 RAC: 0 |
alot of my WU's are getting less credit than claimed. what is causing this? |
Send message Joined: 1 Sep 04 Posts: 137 Credit: 1,769,043 RAC: 630 |
Look at what the other computers that worked on the same unit claimed. The granted credit should be some kind of average. Not sure if this is how LHC is doing it but seti used to drop the highest and lowest claim and then average the rest. This is to prevent cheating. Not to say that you are cheating but there are ways of getting your computer to claim WAY too much credit. With this system such ridiculous claims get thrown out. - A member of The Knights Who Say NI! My BOINC stats site |
![]() Send message Joined: 1 Mar 07 Posts: 47 Credit: 32,356 RAC: 0 |
LHC@home uses a quorum of 3, although 5 results are sent out for each WU. When 3 valid results have been returned, the credit that is granted is the middle claim. 4th and 5th results will also get that amount of credit if valid and returned before the deadline. |
Send message Joined: 18 Sep 04 Posts: 8 Credit: 1,181,841 RAC: 0 |
Seti used to rely on the Boinc Client integer and floating point benchmarks to determine what credit to assign to a certain amount of CPU time. The more opeations per second your computer could generate the more valuable the time of that computers CPUs was. The BOINC client benchmarks were and are not really indicative of how the distributed applications would utilize the execution command sets particular to the CPUs being used in a PC. Optimized clients were introduced which were optimized in the way that they could produce a higher benchmark score due to the utilization of CPU specific command set enhancements, etc. These clients were claiming a lot more credit per time than the not optimized ones. So for example the standard boinc client would claim that during the two one minute benchmark computation sets it could compute, say, 1000 integer ops and 500 floating point ops per second per CPU. The optimized client could on the other side execute, say, 2000 integer and 1200 floating point ops during the test because it used different commands/registers than the standard client. The optimized boinc client would claim 100% more credit in an integer only situation and even 140% moe cedit in a floating point operation situation. The applications utilized in Boinc projects are usually not optimized in that way, so that each and every architecture is utilised at an optimum. So the inflated benchmark scores were not really reflective of the actual contribution of the particular machine running the optimized client. Only in conjunction with an equally optimized application the claims are relative to the contribution. With the standard BOINC client a similar situation arises when looking into different CPUs or even different configurations of the same CPU (Win32, Win-x64, Linux, etc.). Not every application workload executes equally on different CPU architectures, as here differing execution command sets come into play again. And the BOINC client benchmark is only one (actually one integer and one float) possible workload scenario. So, no wonder you get differing credit claims. Afaik the "new" SETI applicions count the amount of actual operations per work unit and that is used to calculate the credit claims. That is how they actually accomplish that usually each claim is within 0.02 points of each other. ( You see if someone uses a 4.x client as that differs considerably in credit claim from platform to platform.) HTH & Cheers |
Send message Joined: 6 Feb 08 Posts: 2 Credit: 5,575 RAC: 0 |
Ah, in some of my others that I did today I get more credit than claimed. It seems it balances out in the end. :D Cheers! |
©2025 CERN