Gents,

A dual core system will usually get the same benchmark as a single core all else being equal. The advantage is that by using both cores you can process twice the work per unit time. So in effect this will double the CPU seconds you report. Under those conditions a dual core system will Claim twice as much credit as an otherwise identical single core system would. Basically it gets twice the throughput.

So you can look at this as twice the work in the same amount of time, or twice the credits in the same amount of time when compared to a singe core system. This also scales up to quad core systems.

In any case the benchmarks will be the same for two systems clocked at the same speed no matter the number of cores, because the benchmark is a function of clocking.

This of course ignores any effects of overclocking. That is a different subject

Looking at some of the top computers shows that they may be (are!) exploiting the credit system. My computer with a standard Boinc client charges about 14 credits per hour while many of the computers in the top RAC list are charging 40 to 60 credits per hour. Is this reasonable? I think not!

In addition some of those computers appear to be doing 1 or 2 hours of work and claiming that they have done 4 to 8 hours of work thereby further inflating their credit claims.

Any fool can create a 'compile your own' Boinc client containing any number of credit exploits. All reputable Boinc projects should ONLY allow an official Boinc client - self compiled clients should be strictly prohibited. I realize that some individuals with odd computer hardware would then not be able to run Boinc projects. In such cases a review of their clients by project developers would be necessary or they would simply be forced to use compatible hardware or just not run Boinc projects.

The reason that an official Boinc client is needed is that many who now process the workunits will be discouraged by continuing credit exploitation (cheating) and simply refuse to contribute any more of their computer time. Potential new users, upon hearing about these exploits and finding that the project developers have failed to take any action, will also not contribute their computer time.

It should also be simple for any project to set a maximum credits per hour per workunit value and enforce it. I realize this is a simplistic solution and may not address all of the projects' requirements.

I find this credit exploitation offensive and the failure by the developers to take any action equally offensive. I contribute my computer time because I believe the science being done here is important. Perhaps I am the crazy one.

There really is not too much that a project can do about this. The BOINC code has been publicly released. It is very easy to compile it so it looks identical to the official version, and yet has some benchmark adjustments. Many of these adjusted clients have been made so they fall with in the normal range of credit claims, but at the top end of them.

In some cases the modifications to the BOINC client are simply taking advantage of special features of the computer for which they are compiled and are in fact producing a more accurate and legitimate benchmark for that system. The problem comes in when the project code does not use those features of the system. This causes the benchmark to be high, but the actual processing time to be slower, thus producing higher credit claims. In that case the project might be accused of not provide an application that takes full advantage of the computing power available, but they are hardly doing that intentionally, it is just difficult to have a special version for every possible special system out there.

As to a limit on the credit per Work Unit. This might work on other projects, but it will not on Rosetta. With the time setting it is possible to run a work unit from between 1 hour and days. With that level of variability where would you set the maximum credit? How would you verify it without overloading the servers? In any case you would still have to accommodate the broad range of possible credit claims made by different systems. With the time setting legitimate credit claims can average from 10 to over 2400 credits for a single work unit. Hourly claims range from 10 to around 50, depending on system speed. So this is just not a workable answer.

As far as the developers not taking action. They have deployed the standard BOINC system. While they have chosen not to use redundancy, the ability to make that choice is part of the server software. They have removed some of the more severe violations from the stats as they are identified. The project team is thinking about a variety of possible solutions to the credit issue, but right now they are focused primarily on killing the bugs in the application. Once that is done, they have stated publicly that they will return to the issue of credit claims and awarding of credits owed from a range of processing problems.

I'll grant credit for this extreme circumstance. We may consider granting credit for all time out errors in the future.

I am really wondering why I never actually received credit for this work unit, even after being promised it would be granted to me...