The claim can even be different from what the pure formula gives from the benchmark figures and the CPU time. When your result arrives in the server the history of results received from this same device is used to compute some more or less obvious*** correction which is applied to the pure formula result to give what will be the official claimed credits.

I am not much enthusiastic about that way of doing which makes it almost unpredictable or even impossible to check if a correction or an improvement that you bring to a device is effective or not and contributes certainly to the suspicion that you are referring to.

After past discussions backstage the techs have reduced the effect and the persistence of these corrections but I am sure they are still in use.

Cheers. Jean.

*** When I say "obvious" I use it regarding both its clarity and its real necessity.

The 1st round of the beta test was done to compute the test mini-workunits/benchmarks. This was done with redundancy to ensure that they were computed properly. We ensured that they went to all platform variations. This gave us a two things: A known mini-result and a base line credit to be awarded for that known result.

The mini workunits take about 10 minutes or so to run.

When a single redundancy result is returned, the mini workunit needs to match up with the value computed during the beta test (otherwise the result is marked invalid and the workunit is sent to someone else).

Additionally, we know how long the mini-workunit took to run on the computer and we know how how much credit the mini-workunit is worth, so based on the cpu time reported by the client we compute the credit for the full result.

After this is done, the credit for the mini workunit is averaged in with this hosts opinion of how much credit should be awarded for the mini workunit so that the value is a fair representation of the overall grid.

It is worth noting that we are not simply relying on a correct computation of the mini-workunit to determine validity. The computer must have already returned many results in a row as valid before it is allowed to go on its own. In addition, all workunits have a random chance of having an extra copy generated for them. This overall method gives high confidence in the quality of the data.

I have just collected a number of single-redundancy DDDT results in a spreadsheet to do some analyzing and one thing is clear: the corrections to the claimed credits discussed above exist but the dispersion is below 0.25 % for this (stable) machine.

Edit: Added "the dispersion"

Cheers. Jean.

The evil explanation is, that even 1 bad result will make you go back to the starting line. From what was posted yesterday, 88.5% was allowed to run a one (wo)man show, so better not cancel that job mid computation or you effect the grids efficiency (if feeling guilty, do )

Meany Me

PS, but seriously Barney, look in your Result Status page and see if your DDDTs have run single or double jointed.

In an effort to be helpful, rather than "dispersion" the word "discrepancy" may be closer to the meaning you are trying to convey. Once again, your observations are most helpful.

Thank you.