| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: How does BOINC calculate claimed credit? |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 15
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
For all the tasks I've run, BOINC has claimed a credit of roughly 85 to 100. I've run ARP, MCM and OPN tasks.
I've noticed, however, that for ARP tasks, everyone else is claiming credits of almost 500, up to 1000. It's no big deal, but I am curious as to why my system is claiming such a low credit on ARP tasks, when everyone else is claiming so much. |
||
|
|
Bryn Mawr
Senior Cruncher Joined: Dec 26, 2018 Post Count: 337 Status: Offline Project Badges: 
|
For all the tasks I've run, BOINC has claimed a credit of roughly 85 to 100. I've run ARP, MCM and OPN tasks. I've noticed, however, that for ARP tasks, everyone else is claiming credits of almost 500, up to 1000. It's no big deal, but I am curious as to why my system is claiming such a low credit on ARP tasks, when everyone else is claiming so much. It takes time for your system to get used to the different types of task. You will probably find that tasks claiming 50 credits are actually receiving significantly more when they validate. Your system will remember this and ask for more the next time. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I am getting more credit for ARP tasks when the tasks validate: It appears to be the average credit claimed by everyone who received and completed the task (for any project, actually).
I'll have to start running ARP tasks again to see if my system does start asking for more credit, but it takes sooo long for these to validate that I just stopped asking for them. |
||
|
|
TPCBF
Master Cruncher USA Joined: Jan 2, 2011 Post Count: 1932 Status: Offline Project Badges: 
|
I am getting more credit for ARP tasks when the tasks validate: It appears to be the average credit claimed by everyone who received and completed the task (for any project, actually). That is correct. ARP1 has a quorum of 2 and you get the average of the points claimed by both hosts.Apparently the actual work in each WU can widely differ, and so the runtime and the claimed credit.I am pretty sure that there is a post in the ARP1 forum better explaining this. This works in other projects that are multi-quora as well, but in ARP1, the difference can just be far more pronounced. And the "loss" or "gain" compared to your wingman can work both ways. I'll have to start running ARP tasks again to see if my system does start asking for more credit, but it takes sooo long for these to validate that I just stopped asking for them. What is the rush?  The system requirements for ARP1 are much higher than any other project, and also the runtime of its WUs is far higher than most other projects. And runtimes are in general longer, specially on older hardware, so it can be several days before your wingman returns its result and the WU can be validated. That alone makes it take longer to get a validated result than with most other projects, where return and validation can happen within a matter of an hour or two... That is currently compounded by the fact that the whole setup is officially still kind of in a "test" environment and there also have been some serious download issues, which in case of ARP1 show up more because of multiple rather large files being downloaded for each WU...  Ralf  |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I am getting more credit for ARP tasks when the tasks validate: It appears to be the average credit claimed by everyone who received and completed the task (for any project, actually). That is correct. ARP1 has a quorum of 2 and you get the average of the points claimed by both hosts.Apparently the actual work in each WU can widely differ, and so the runtime and the claimed credit.I am pretty sure that there is a post in the ARP1 forum better explaining this. This works in other projects that are multi-quora as well, but in ARP1, the difference can just be far more pronounced. And the "loss" or "gain" compared to your wingman can work both ways. Ralf I understand all this -- the credit claimed reflects the CPU time expended in completing the unit, which can vary between units. But that is not the issue here. Over all the units my system has received (OPN, MCM and ARP), it has never submitted a claim above 115 or 118, and those were on a couple of MCM units that took a little longer to complete. The OPN and MCM tasks all require about 2 CPU hours to complete. Meanwhile, the ARP units take 10 to 11 hours to complete, yet my system has never claimed more than about 95 to 98 for any of them -- the same as for everything else. It just seems very strange that CPU time does not seem to count for very much (if anything) when my system is adding up the credit it is going to claim, and I am curious as to why. [Edit 1 times, last edit by Former Member at Sep 23, 2022 5:01:08 PM] |
||
|
|
TPCBF
Master Cruncher USA Joined: Jan 2, 2011 Post Count: 1932 Status: Offline Project Badges:
|
I am getting more credit for ARP tasks when the tasks validate: It appears to be the average credit claimed by everyone who received and completed the task (for any project, actually). That is correct. ARP1 has a quorum of 2 and you get the average of the points claimed by both hosts.Apparently the actual work in each WU can widely differ, and so the runtime and the claimed credit.I am pretty sure that there is a post in the ARP1 forum better explaining this. This works in other projects that are multi-quora as well, but in ARP1, the difference can just be far more pronounced. And the "loss" or "gain" compared to your wingman can work both ways. Ralf I understand all this -- the credit claimed reflects the CPU time expended in completing the unit, which can vary between units. But that is not the issue here. Over all the units my system has received (OPN, MCM and ARP), it has never submitted a claim above 115 or 118, and those were on a couple of MCM units that took a little longer to complete. The OPN and MCM tasks all require about 2 CPU hours to complete. Meanwhile, the ARP units take 10 to 11 hours to complete, yet my system has never claimed more than about 95 to 98 for any of them -- the same as for everything else. It just seems very strange that CPU time does not seem to count for very much (if anything) when my system is adding up the credit it is going to claim, and I am curious as to why. Ralf PS: And just to be clear, this is not "BOINC" calculating the credit, it is the WCG project that is doing so. And 1 BOINC point (as seen of external stats sites like BOINCstats, or in SNURKs provided signature  ) is in fact 7 WCG points/credits. This has histroical reasons due to the inception of WCG before they started to use the BOINC system and using a different benchmark system. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
If it is the WCG that is calculating my "claimed" credit, then I am at a further lost to understand this. It will take my system the same CPU time to complete one ARP unit as it will take my "wingman's" system, yet he/she gets a claimed credit 5 or 7 times larger than I do? There has to be a good explanation for this that hasn't been mentioned so far, because it makes absolutely no sense right now.
----------------------------------------[Edit 1 times, last edit by Former Member at Sep 23, 2022 6:51:55 PM] |
||
|
|
TPCBF
Master Cruncher USA Joined: Jan 2, 2011 Post Count: 1932 Status: Offline Project Badges:
|
If it is the WCG that is calculating my "claimed" credit, then I am at a further lost to understand this. It will take my system the same CPU time to complete one ARP unit as it will take my "wingman's" system, yet he/she gets a claimed credit 5 or 7 times larger than I do? There has to be a good explanation for this that hasn't been mentioned so far, because it makes absolutely no sense right now. No. IIRC, part of the processing is that two different hosts can come to the same result by two different paths, thus different amounts of CPU time. That is something that is build in the logic of that particular client application. The whole ARP project is one that calculates probabilities, using different models. I will see if I have a bit more time this afternoon or this evening to find that article/post in the ARP subforum that explains all of this.It is years now that I read this, as I was (as pretty much all other WCG users that chose to crunch ARP1 when it was released) a bit confused on how this is exactly working. And ARP1 works internally distinctively different than any other of the WCG projects.Ralf |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
OK, that makes sense -- somewhat. For the most part, my CPU time is much less than the wingman's. There are, however, a couple of instances where that is not the case, yet my credit claim is still less than 100, while the other guy's is 400 or more.
There is one instance where I have a claim for 83.6 on 9.88 hours, while one wiingman (there are actually 5 of us reporting on that unit) claims 646.2 on 8.36 hours. Like I said, it begins to make sense -- somewhat. |
||
|
|
TPCBF
Master Cruncher USA Joined: Jan 2, 2011 Post Count: 1932 Status: Offline Project Badges:
|
OK, that makes sense -- somewhat. For the most part, my CPU time is much less than the wingman's. There are, however, a couple of instances where that is not the case, yet my credit claim is still less than 100, while the other guy's is 400 or more. It's not to say that there isn't a glitch in the whole system. There is one instance where I have a claim for 83.6 on 9.88 hours, while one wiingman (there are actually 5 of us reporting on that unit) claims 646.2 on 8.36 hours. Like I said, it begins to make sense -- somewhat. But the cold hard truth is that the folks at Krembil are (hopefully!) working on getting the download issue fixed, and other things of the pre-move functionality restored. I don't think that anyone has the time or interest to look into issues like these until this is all "working". The same pretty much goes for those never-ending MCM1 jobs. They don't happen often, so some times more than others, to the point that the pre-move techs pretty much said that it happens so infrequently that it is not worth to investigate. Oh well... Ralf |
||
|
|
|