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?

The situation is similar on every PC (PYRT and cut is inefficient compared to mutEGF).
If you were having at least a Core i3 system (or overclock your existing system's FSB), the gap would be much less between the efficiency of those workuints.
From the community's point of view it's not a good idea to abort the inefficient ones. But from your POW I understand your concern.
I was asking a similar question regarding long workunits. It worth a look at there, the answers are nothing specific, mostly BS in my terms.

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

And it's not completely compatible with the reality.
The application on my machine is always the same, I only run the "short" ones on the GT240.
The WUs, i.e. the input data for the application, are of different type.
Within one type of WU the runtimes are very consistent, far less than 5% methinks.
With one type of WU compared with another type the difference goes are at least 20%, between the extremes cut and mutEGF even over 300%.
The setup of the computer is the same for all, tested for maximum efficiency:
- Skript to give them niceness of -5
- No SWAN_SYNC
- BOINC 6.10.58, ubuntu 10.04, C2Q9450 @ 3.2GHz, GT240 running newest drivers at maximum clock

So in theory they should all get roughly the same amount of credits per hour, be that CPU-time or clock-time.

As I said in my opening post, credits are the sole responsibility of the project, they are fixed for each type of WU and have no input from my machine (besides the bonus).

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.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

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: I totally agree and personally I have a unique thread on the subject: http://www.gpugrid.net/forum_thread.php?id=2480

Today I received two tasks being performed simultaneously by two users, the problem of three days on one side and five on the other.

The truth makes me want to cancel these two tasks that I just received ... Greetings.

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.

gdf

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.

It's on the same machine, all WUs have exactly the same resources, be it RAM (8GB), Nvidia-card (GT240), nice factor, whatever. All run in exactly the same environment but generate extremely different amounts of credit per hour, the extremes are 238 (cut) vs. 750 (mutEGF).

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.

Does that mean 3 days or 5 days deadline?

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

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

The sooner you put an end to it and the waste of resources it promotes the better.

It's on the same machine, all WUs have exactly the same resources, be it RAM (8GB), Nvidia-card (GT240), nice factor, whatever. All run in exactly the same environment but generate extremely different amounts of credit per hour, the extremes are 238 (cut) vs. 750 (mutEGF).

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

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.

Does that mean 3 days or 5 days deadline?[/quote]


Most of the results are already coming back in 3 days. 4 days could be a good compromise, but we could keep it to 5 and see how it goes.

gdf

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

Here we go go for some examples of both extremes:
cut (with fixed credits of 5929.17476851852)
216-KASHIF_HIVPR_cut_ba1-71-100-RND5282_0: Run time: 89793.187448, CPU time: 1398.37
170-KASHIF_HIVPR_cut_ba1-70-100-RND8805_1: Run time: 89846.026353, CPU time: 1467.29

mutEGF (with fixed credits of 10591.0960648148)
p46-IBUCH_1_mutEGF_110726-15-20-RND1842_5: Run time: 50729.373009, CPU time: 1917.21

and some other ones:
GS_so (with fixed credits of 12822.1759259259)
357-KASHIF_HIVPR_GS_so_ba1-16-100-RND7458_1: Run time: 96936.183427, CPU time: 1260.3
122-KASHIF_HIVPR_GS_so_ba1-15-100-RND1587_2: Run time: 96907.045078, CPU time: 1270


PYRT (with fixed credits of 2771.44097222222)
184-IBUCH_PYRT_110728-27-50-RND8461_0: Run time: 33667.697068, CPU time: 1932.94

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

OK,
the problem is that the slow simulations use a slower version of the algorithm.
IN one case the workunits had started before this option was available. In another case, it was not enabled by mistake.

We have a script which control the compliancy of new workunits and probably this new parameter is not tested. We will fix it in new wokunits.

gdf

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

Not really, because on my host 43404 *PYRT* have the lowest hourly credit rate of all, with under 0.5 (bonus) credit per (runtime) second.

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.

Not really.
To quote my starting post here:

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

Not 3x, but 2.5x the credits for EGF compared to PYRT.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

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.