The current method of calculating credit is broken.

The code that is executed to test CPU speed is totally different to the code that the "worker" clients are using later on while doing science.

So if you have two machines that get the same benchmark results, it can happen that one of them is
twice as fast as the other while doing science.

The faster machine gets only 1/2 credit per WU,
and also drags down others when credit is granted.

To remedy this, the participating projects should
send out calibration WUs (with know number of FLOPS)
to measure the speed of their "worker" clients.

Each project should do its own benchmarking!

Regards Hans

This is possible on a project by project basis. CPDN for example gives an set amount of credit per timestamp. The client will still need to do benchmarks though for estimating the amount of work to download. It is also probaly easier for new projects to use the canned (core client) method for generating credit than creating their own internal method.

John Keck -- BOINCing since 2002/12/08 --

> This is possible on a project by project basis. CPDN for example gives an set
> amount of credit per timestamp. The client will still need to do benchmarks
> though for estimating the amount of work to download. It is also probaly
> easier for new projects to use the canned (core client) method for generating
> credit than creating their own internal method.

Still, though, there is something about it. It may very well be that the optimization settings for the core client is way higher than for the science application. In this case the client will request less credit than usual.

By moving the benchmarks into the client library (doesn't even need to be in the application code really as long as it is compiled with the application) then the numbers will not be as scewed due to different optimizations.

> > This is possible on a project by project basis. CPDN for example gives an
> set
> > amount of credit per timestamp. The client will still need to do
> benchmarks
> > though for estimating the amount of work to download. It is also probaly
> > easier for new projects to use the canned (core client) method for
> generating
> > credit than creating their own internal method.
>
> Still, though, there is something about it. It may very well be that the
> optimization settings for the core client is way higher than for the science
> application. In this case the client will request less credit than usual.
>
> By moving the benchmarks into the client library (doesn't even need to be in
> the application code really as long as it is compiled with the application)
> then the numbers will not be as scewed due to different optimizations.
>
Having one piece of code generate the benchmarks makes cross project scores possible. Since most of the projects will not have enough WUs for all of the interested volunteers all of the time, it is fun to compare total cobblestones across all projects. (for a while, I was dropping position in each of the projects I am attached to, but gaining position overall). Since BOINC is cross project, the scoring should be as well.

My post didn't seem to be as clear as I had hoped, let me try again.

While I like the idea of doing benchmarks or credit calculations in the science applications, the standard work manager benchmarks and credit calculations will still need to be done. So in my opinion there is no point in trying to change seti over until the BOINC benchmarks are working properly, since then the developers would have to work on both.

John Keck -- BOINCing since 2002/12/08 --