| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: Suggestions / Feedback
Thread: Hey, Stop Punishing Me! |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 21
|
|
| Author |
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Augustine,
----------------------------------------Then i see it, then i dont, but caches work wonders  It beats me how to understand why your benchmarks run on 2.2ghz and the actual processing only at 1 ghz. Some Linux expert is surely able to lead the way to 'full' throttled crunching. ciao edit.... and when finally posting it's back again.
WCG
----------------------------------------Please help to make the Forums an enjoyable experience for All! [Edit 1 times, last edit by Sekerob at Mar 20, 2007 10:27:11 PM] |
||
|
|
ebahapo
Cruncher Joined: Nov 2, 2005 Post Count: 45 Status: Offline Project Badges: 
|
It beats me how to understand why your benchmarks run on 2.2ghz and the actual processing only at 1 ghz. Some Linux expert is surely able to lead the way to 'full' throttled crunching. In Linux the CPU clock governor doesn't consider processes running with idle priority when deciding whether the system load warrants an increased CPU clock frequency. It makes sense, for it's fair to assume that a process at idle priority has no dead-line. In that system specifically, the CPU remains at 1GHz. However, the BOINC client runs the benchmarks with normal priority, therefore when the CPU clock governor notices the increased system load, it pegs the CPU clock frequency. In that system, to 2.2 GHz. Thus, the GFlOps reported by the benchmark is not the same available to the applications. My proposed patch makes sure that both run at the same priority. On Linux systems which enabled the CPU clock governor, clients won't "overclaim" anymore and on those systems which didn't enable it, there'll be no difference. I could set the system to peg the CPU clock frequency (powersave -f), but it's a server in a rack and letting the CPU clock frequency vary dynamically is preferable, as I don't want to increase the closet temperature and jeopardize the rack reliability to crunch for WCG. HTH  |
|||
|
||||
|
ebahapo
Cruncher Joined: Nov 2, 2005 Post Count: 45 Status: Offline Project Badges:
|
By running the benchmarks with the same idle priority as the applications, the system now claims an amount of credit closer to the granted credit:
----------------------------------------
And no punishments! |
|||
|
||||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Many other projects assign credits based on the final run-time and the number of operations in the WU. WCG is the only project in which these systems are punished. If counting such systems as outliers is necessary, fine, but it's not fair to have them punished for contributing to WCG. One option is to vote with your feet. Just uncheck participation in any project with the penalty. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
I hope the voting with feet is after ritually correct washing procedures
---------------------------------------- The issue was fixed anyway as the 'home compile' was too optimized to consider it is actually working on 32 bit science and not 64 bit.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I hope the voting with feet is after ritually correct washing procedures You don't want to know the ritual... But some of those new machines are not very convenient for us foot voting people. The issue was fixed anyway as the 'home compile' was too optimized to consider it is actually working on 32 bit science and not 64 bit. Kind of, but it still pertains to any machine that "overclaims" for any reason. Even though the credits are fixed, the "overclaiming" system is penalized in some WCG projects by having it's credits cut in half. As far as I can see the only solution is to vote-with-feet and not run the project. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
No, the correct solution is to identify the reason why BOINC is broken, and fix it. The original reason for the penalty was that a number of people were using a third party "optimised" BOINC build that faked the benchmark results. You can imagine: this distorted the whole credit/benchmark system.
It was no surprise that when the penalty was implemented, everybody went back to the official client. Leaving the penalty in place is just a precaution, and it helps members identify issues with their benchmark early on. Sure, it's going to seem unfair if you didn't do anything deliberately. But it's no less fair than getting more points than you have earned. If anyone needs help identifying a benchmark problem, we are here to help. And a footnote: only outrageously inflated claims are penalised. If you (or anyone) is being penalised, something is wrong. If you are just claiming a bit high, the WCG credit algorithm will take that into account and give you the normal credit. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
No, the correct solution is to identify the reason why BOINC is broken, and fix it. Not easy if the machine is off site. Off site machines are also a big problem with the recent rash of bad Genome Comparison WUs. The original reason for the penalty was that a number of people were using a third party "optimised" BOINC build that faked the benchmark results. You can imagine: this distorted the whole credit/benchmark system. If the credit system is fixed, why would it matter what anyone claims? It was no surprise that when the penalty was implemented, everybody went back to the official client. Except for the people who just left because they couldn't change the client for some reason. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
There are two issues here.
1. You are unhappy about the penalty. Well, we're all pretty fed up with the BOINC credit system. As you note, if the credit system is fixed, it won't matter what people claim. The problem is, it isn't fixed. Not by a long way. Different projects are exploring ways around the weaknesses in the BOINC system, but there is no official BOINC solution yet. We live in hope. 2. You seem to have trouble accessing some of your machines. I needn't remind you that you shouldn't run WCG on any computer without permission. So I'm assuming you have access to these computers, but it's inconvenient. There are ways around this. BOINC is quite useful in that respect. You can connect remotely to BOINC running on any of your hosts, and manage it from your desk. There are even tools like BOINC View (and, to some extent, account managers) that will let you manage all your hosts at once. Setting this up isn't terribly easy, though. For remote access to upgrade BOINC, you would need some remote desktop solution (or SSH; whatever your platform requires). Is this helpful? |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
1. You are unhappy about the penalty. Not unhappy, happiness is an internal issue. Just trying to understand the reasoning. Well, we're all pretty fed up with the BOINC credit system. As you note, if the credit system is fixed, it won't matter what people claim. The problem is, it isn't fixed. Credits aren't determined server side? 2. You seem to have trouble accessing some of your machines. I needn't remind you that you shouldn't run WCG on any computer without permission. So I'm assuming you have access to these computers, but it's inconvenient. Of course I have permission, but some machines are in locations that I rarely visit. Reliability is key. The users are not an option, they're lucky if they can remember how to turn the machine on. There are ways around this. BOINC is quite useful in that respect. You can connect remotely to BOINC running on any of your hosts, and manage it from your desk. There are even tools like BOINC View (and, to some extent, account managers) that will let you manage all your hosts at once. Setting this up isn't terribly easy, though. BoincView is great for lans. It doesn't work off site. Account managers like BAM? How does that help? We don't seem to be getting anywhere, useless arguments are a waste of time. Anyway, thanks for all your work, your replies, and for a very nice project. |
||
|
|
|