- If it has (own or 3rd party) applications optimized for specific platforms, then these clients will have a low claimed credit/granted credit ratio. If these clients are in the majority, then the majority of clients will be considered to underclaim. Or in other words, the project will be considered to be overly generous. The project credit will be corrected downward. That means that older machines, or machines for which no optimization exists, will get less credit than in projects without optimized applications .
- If a project on the other hand has lots of optimized Boinc clients (style 5.5.0, 6.1.0), then these will have a high claimed credit/granted credit ratio. These overclaimers will cause project credit to be corrected upward. So... in theory the new calculation would make it interesting for a project to have lots of optimized Boinc clients... Mmmmm, the irony.

My reasoning might be completely wrong. Any of the Boinc guru's can correct me? Starting to hold my breath in 1... 2... 3...

tutta,

First off, thanks for a resonable, flame-retardant reply! :) (They're generally rare when discussing this issue)

I had been mulling in my mind how the first example (optimized apps) would affect things and I had considered that if enough were running then it would start to affect even the median (always bear in mind they're using median, not mean) operations to complete tasks. I know it would have to grow to be a significant portion of all clients running the app before it would affect the setting, but I'm not sure exactly how many. I'm going to speculate that their line of reasoning on this is that once you reach a point where (for example) 1/2 of all the clients are running an optimized client (again, it may be more or less... I just don't know), then the project should probably be running something similar as it's stock app. This sounds reasonable to me, but others may disagree.

My personal opinions generally come from an approach of "Let's just get the science done", so to me this would be a good thing. I'd rather have a bunch of users thwacking the heads of the project admins to get the stock app improved than having them thwacking their heads because they think some alteration needs to be made to credit.

I know some will argue that it means those that invent the improvements won't see any long-term benefit, but I disagree. The person that first implements a working optimization won't affect the average until LARGE numbers of people are running it. He/she may enjoy a huge advantage in the project for a time, but (unless they never share the app and the project developers never figure out the same method) eventually they're competing against large numbers of volunteers going just as fast. They no longer have a significant advantage anyhow at that point.

As for optimized CLIENTS rather than apps, I *think* that's a non-issue. Since (again, I *think*) this method no longer uses a benchmark * time based claim, but rather counting operations (everyone calls it flop counting, but to the best of my knowledge it's actually a combination of both integer and float ops), I don't think there's a change in the client that could affect the claim (again... I'm relatively ignorant of the details on this, so I might be totally wrong). It does require the application to report these amounts to the client (and thus the server) and I'm not sure if they've worked the kinks out of that or not though.

---

As for optimized CLIENTS rather than apps, I *think* that's a non-issue. Since (again, I *think*) this method no longer uses a benchmark * time based claim, but rather counting operations (everyone calls it flop counting, but to the best of my knowledge it's actually a combination of both integer and float ops), I don't think there's a change in the client that could affect the claim (again... I'm relatively ignorant of the details on this, so I might be totally wrong). It does require the application to report these amounts to the client (and thus the server) and I'm not sure if they've worked the kinks out of that or not though.

Operation counts can be gamed in a similar way to the benchmark * time method. The primary defense against this in the new automatic credit corrections system is taking the mean of a good sized sample of results. A project would have to have at least 2,000 bad clients or 1/5 of active clients before it would become a serious problem (rough guess, the actual number depends on the exact formula used). Also it won't instantly go bad if one too many clients is off, it just gets a little more off for each one.

I agree this is a great thing for project administrators and BOINC in general. There may be problems in the future adapting this system to account for GPU and other non-CPU resources used. However I don't think they will be as insurmountable as some participants have made them seem.

---

BOINC WIKI

BOINCing since 2002/12/8