As credits are something that is been decided on by the project on the server per WU (-type?), at least there is no connection between anything on my machine and the credits granted (besides the bonus), I'd like to know whether there is any sign about the efficiency of my card for certain WUs that get more per hour.
I've crunched some WUs lately on my GT240, and I got a very inconsistent ratio of either Credits per CPU-hour or per wall-clock-hour. Even with for me quite similar looking WUs from the same researcher, like KASHIF_HIVPR give very different amounts:

KASHIF_HIVPR_cut_ba1 (7,411.47 claim): 238 c/h clock, 15.000 c/h CPU
KASHIF_HIVPR_GS_so_ba1 (12,822.18 claim): 476 c/h clock, 37.000 c/h CPU
IBUCH_1_mutEGF (10,591.10 claim): 750 c/h clock, 20.000 c/h CPU
IBUCH_PYRT (2771,44 claim): 297 c/h clock, 5.200 c/h CPU

(numbers are for claims, as I get 50% bonus, grants are more, but the same factor for all)

Does that mean I should delete all PYRT and cut (if I would manage to write a script for it), because they are absolutely inefficient on my machine?
Is there enough mutEGF in store to restrict me to that best fitting type?
____________
Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

Does that mean I should delete all PYRT and cut (if I would manage to write a script for it), because they are absolutely inefficient on my machine?

I read this answer by gdf:

APPLICATIONS
There are two applications which can be selected in your project preferences, acemd2 and acemd_long. By default both are selected. The acemd2 workunits are normal workunits to complete in few hours on the most common cards of the time (up to 3 times slower than top cards). The acemd_long workunits are several times longer and should complete in maximum 12 hours on the top cards.

CREDITS
The credits are returned by the workunit using an estimate of the amount of flops based on number of atoms and number of iterations. Variation of 10-20% between workunits which take the same time to complete are probably normal and can depend on many factors. Some as simple as the FFT uses multiple of 2 for one workunits and not for another one. acemd_long doubles this estimate to compensate for the burden of having your machine computing for as much as 12 hours on a top card and the additional risk of losing the credits to due to a crash.

DEADLINES
The server deadline is 5 days. The server assigns 50% more credits if you return within 24 hours and 25% more credits within 48 hours. After 3 days the server reissue a workunit to make sure it is computed as fast as possible, although if the first one comes in, it cancels the new one immediately if it is not being computed already.

Hope it helps. We should probably put this somewhere more visible.

gdf

Ah, and regarding the deadline:
Every WU that takes more than 3 days is de facto a wasted one, the real deadline for this project is 3 days. You just keep it at 5 days to give out credits to old machines who should never even begin to run a WU here. The current setup leads to a big waste of ressources from cards, who should either be retired or go to other projects with less strict returning requirements.

Hi,
there is further case which adds variability to a workunit. This is depending on GPU RAM available. If you have less, the code is slower because it needs to accomodate for that with a different algorithm. We can correct for that in the next application release.

300% slower it should not happen unless we have made a mistake in the input or there is some sort of other problem.

Regarding the 3-5 to days deadline. I agree. We are probably going to remove it. We have passed already from 2 to 3. It was created when we did not have the short and long application and is very complicated to do it once we will do a server software update.

Regarding the 3-5 to days deadline. I agree. We are probably going to remove it.

We can try to look at those two WU locally. 3x it should be impossible.

Let me add also that *EGF*, *EGFR*, *PYRT*, *Fab* have a x2 of credits due to their unavoidable higher load of the CPU. In these experiments, we have to use a little iterative script that doesn't run on the GPU...
That was an old decision we took. Give extra credits for the burden of these WUs.

Hope this helps to explains the credit differences.

i

Let me add also that *EGF*, *EGFR*, *PYRT*, *Fab* have a x2 of credits due to their unavoidable higher load of the CPU. In these experiments, we have to use a little iterative script that doesn't run on the GPU...
That was an old decision we took. Give extra credits for the burden of these WUs.

Hope this helps to explains the credit differences.

i

Let me add also that *EGF*, *EGFR*, *PYRT*, *Fab* have a x2 of credits due to their unavoidable higher load of the CPU. In these experiments, we have to use a little iterative script that doesn't run on the GPU...
That was an old decision we took. Give extra credits for the burden of these WUs.

Hope this helps to explains the credit differences.

I have to appologize and rectify.

Unlike *EGF*, IBUCH_PYRT_* do not have the credit compensation.
A new batch of IBUCH_*_affwtPYRT_* has just been submitted which includes the credit compensation which, is likely be discontinued for acemd "short" WUs.

Additionally, and regarding these annoying batch of *_PYRT_*, let me say to those volunteers that deliberately cancel them, keep in mind that doing that has direct negative impact to the underlying research. After 3 cancellations (error, abortion,..) WUs die. That is no data for us.

We make an effort to be fare in granting credits to computation. We ask you to please also think twice before cancelling.

Many many thanks

Completed the first p18-IBUCH_2_affwtPYRT_110908-0-50-RND0537_0 - that's much more comparable, even if not a little too far the other way. I've received two of the older *PYRT* since then, but don't worry, they'll be completed as normal.

Thanks for looking into it.