Advanced search

Message boards : Number crunching : How are credits and work done related?

Author Message
Profile Saenger
Avatar
Send message
Joined: 20 Jul 08
Posts: 134
Credit: 23,657,183
RAC: 0
Level
Pro
Scientific publications
watwatwatwatwatwat
Message 21920 - Posted: 30 Aug 2011 | 15:41:21 UTC
Last modified: 30 Aug 2011 | 15:42:29 UTC

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

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 2343
Credit: 16,201,255,749
RAC: 0
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21924 - Posted: 30 Aug 2011 | 19:34:45 UTC - in response to Message 21920.
Last modified: 30 Aug 2011 | 19:36:32 UTC

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.

Profile Saenger
Avatar
Send message
Joined: 20 Jul 08
Posts: 134
Credit: 23,657,183
RAC: 0
Level
Pro
Scientific publications
watwatwatwatwatwat
Message 21936 - Posted: 2 Sep 2011 | 12:10:32 UTC
Last modified: 2 Sep 2011 | 12:10:57 UTC

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

Profile Carlesa25
Avatar
Send message
Joined: 13 Nov 10
Posts: 328
Credit: 72,619,453
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21937 - Posted: 2 Sep 2011 | 14:26:47 UTC - in response to Message 21936.


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.

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1957
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21938 - Posted: 2 Sep 2011 | 16:39:17 UTC - in response to Message 21937.

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

Profile Saenger
Avatar
Send message
Joined: 20 Jul 08
Posts: 134
Credit: 23,657,183
RAC: 0
Level
Pro
Scientific publications
watwatwatwatwatwat
Message 21939 - Posted: 2 Sep 2011 | 16:55:48 UTC - in response to Message 21938.

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

Dagorath
Send message
Joined: 16 Mar 11
Posts: 509
Credit: 179,005,236
RAC: 0
Level
Ile
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21944 - Posted: 3 Sep 2011 | 7:45:04 UTC - in response to Message 21938.

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.

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1957
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21954 - Posted: 4 Sep 2011 | 13:01:07 UTC - in response to Message 21939.
Last modified: 4 Sep 2011 | 13:02:28 UTC


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

Profile Saenger
Avatar
Send message
Joined: 20 Jul 08
Posts: 134
Credit: 23,657,183
RAC: 0
Level
Pro
Scientific publications
watwatwatwatwatwat
Message 21955 - Posted: 4 Sep 2011 | 13:21:05 UTC - in response to Message 21954.
Last modified: 4 Sep 2011 | 13:22:04 UTC

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

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1957
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21956 - Posted: 4 Sep 2011 | 14:38:50 UTC - in response to Message 21955.
Last modified: 4 Sep 2011 | 15:43:22 UTC

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

ignasi
Send message
Joined: 10 Apr 08
Posts: 254
Credit: 16,836,000
RAC: 0
Level
Pro
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwat
Message 21962 - Posted: 5 Sep 2011 | 10:37:08 UTC - in response to Message 21955.

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

Richard Haselgrove
Send message
Joined: 11 Jul 09
Posts: 1589
Credit: 6,560,769,351
RAC: 5,635,230
Level
Tyr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21963 - Posted: 5 Sep 2011 | 10:44:40 UTC - in response to Message 21962.

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.

Profile Saenger
Avatar
Send message
Joined: 20 Jul 08
Posts: 134
Credit: 23,657,183
RAC: 0
Level
Pro
Scientific publications
watwatwatwatwatwat
Message 21964 - Posted: 5 Sep 2011 | 13:04:40 UTC - in response to Message 21962.

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

ignasi
Send message
Joined: 10 Apr 08
Posts: 254
Credit: 16,836,000
RAC: 0
Level
Pro
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwat
Message 21978 - Posted: 8 Sep 2011 | 11:04:43 UTC - in response to Message 21964.

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

Richard Haselgrove
Send message
Joined: 11 Jul 09
Posts: 1589
Credit: 6,560,769,351
RAC: 5,635,230
Level
Tyr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21979 - Posted: 8 Sep 2011 | 14:25:00 UTC - in response to Message 21978.

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.

Post to thread

Message boards : Number crunching : How are credits and work done related?

//