Of course we are interested. I need to take some time to read these papers ... but thank you for these papers ...

Thanks I was looking for an explanation of the calculations.

I was trying to work out the efficiency of GPU computation compared to CPU computations based on power consumption of the device.

My first successful WU http://www.gpugrid.net/result.php?resultid=400387 provided me with 4,214.28.

By my calculations from the equations you provided that means that:

14564551680 = MFLOP per WU + approx MIPS per WU

How can I work out the MFLOP per Wu or the approx MIPS per WU?

Rob

For transparency towards other projects, we have published even more in details how credits are computed.

Give a look if you are interested.

GDF

Severals users like http://www.gpugrid.net/results.php?hostid=22576 have seen an increase of their points attribuated to their WU... Is it normal ? Is it to compensate, if there is, a decrease of users crunching GPUgrid for milkyway ?

Thank you !

That sounds good.......It would be nice to finally see a standard used in all three projects.....And this will also be a big help in the future when more GPU projects come online.....

Sounds great! :D

Now if the server would send the WUs per GPU and not per CPU, it would make it a lot easier for me to send them back within 24 hours... ;-)
____________

pixelicious.at - my little photoblog

Well, I have to admit to being a bit baffled by the choice to award more for 24 hour returns. If you really needed work done within 24 hours, then why not just set the deadline as such? If the idea behind this new credit policy is to drive away persons with slower cards, then I think you will be successful. I think that you should also modify the compatible cards FAQ to note this policy (especially since the minimum recommended cards at 64 shaders will be hard pressed to complete much work in under 24 hours).

Wouldn't a simple adjustment to the flops multiplier be an easier way to come into credit alignment with other projects?

So, I have just finished one task. I have another 2 WUs in the queue, that I got this morning and know that I cannot complete in 24hrs (i.e. tomorrow morning). What I should do is abort the waiting task and the one just started and get another fresh WU that I know I can complete in 24hrs and get 50% more credit for.

I mean why should I crunch for less credits than I have to?

I think this may turn out to be counter-productive.

Yes, I don't fully understand what the new credit scheme is going to be or what the 24 hour deal is about either ...

This is the first time in boinc history that I have to by a new slower CPU to math my ATI 260 GPU(My now AMD 8650 Triple-Core), probably a AMD 5600, very nice anyway! Long Life to Gpugrind!

Regards Thomas

The best is to limit the Wu per host not per core.
Or is there a other way to limit the Wu on a multicore system?

cu JagDoc

One of the problems that this project has, much like Milky Way is that task x+1 relies on task x being returned. What this means is that the tasks are more of a task *STREAM* ...

With that in mind, those that can return tasks faster allows the project to get to the "end" of the stream faster than if they have to wait for the deadline, or longer, to occur.

Just as I, and others, have suggested that projects that are in testing (particularly alpha testing) should award at higher rates, those that enable the project to get to their goals more quickly should also be awarded. I have also noted and supported those projects where you are rewarded even when the tasks crash if the crashes are through no fault of yours (CPDN comes to mind) ...

Yes, if you have a slower card you will not get the higher rate of award. But, should this not encourage you to get and apply a faster card? I know it may move up my schedule to replace the 9800GT I have ...

I suppose that I may be a little on the project side here because I will certainly be earning the higher rate on much of the work I do as the i7 has two GTX 295 cards and the speed at which they do the work means that I will likely see a lot of higher pay... the GTX280 and the 9800 on the other hand will be catch me if you can ...

GDF,

You may need to put in a watchdog to see if participants are killing tasks at a higher than expected rate to clear the queues ... and on the other side, it would be nice if there was a project side way to limit the queue ... for example, maybe it would be in my interest to allow the machine with the 9800 to ONLY queue one task at a time, maybe even none... the same situation with the GTX280 where I know I have had as many as 3 spares waiting ... cutting that back to two would serve BOTH of us better ...

AND, if you do get that coded and working, CPDN is interested in that kind of throttling too (well, at least one project person was) ...

Last note, it might be nice if you posted the payment rates in a sticky in the web and server forum with this new information ...

I suppose that I may be a little on the project side here because I will certainly be earning the higher rate on much of the work I do as the i7 has two GTX 295 cards and the speed at which they do the work means that I will likely see a lot of higher pay... the GTX280 and the 9800 on the other hand will be catch me if you can ...

One of the problems that this project has, much like Milky Way is that task x+1 relies on task x being returned. What this means is that the tasks are more of a task *STREAM* ...

With that in mind, those that can return tasks faster allows the project to get to the "end" of the stream faster than if they have to wait for the deadline, or longer, to occur.

Yes, if you have a slower card you will not get the higher rate of award. But, should this not encourage you to get and apply a faster card? I know it may move up my schedule to replace the 9800GT I have ...

hmm - only a matter of local cache size. even my old 9600gt runs them under 24 hours. so if i run @ 0.01 cache...
....and donate a candle to santo improvisario each and every day...

Many workunits can run on a 9600GT under 24 hours, but the latest larger units (the 42xx credit ones) really push the limit. I have seen one OC 9600GT (1800 shader) which took about 25 hours to finish one of these. Your OC of 1850 might get you under 24 hours, but it will be very close. So, for most who are not willing to push their 9600 to the edge in OC, the larger units will edge just over the 24 hour mark. Indeed, even a 96 shader card needs to be pushed up to the 1650-1700 shader clock range to break the 24 hour deadline.

[Thus my question about simply shortening the deadline...

...instead of buying a new $500(US) GPU, why not spend much less than that on on older single core machine with PCIe slots?

So,
we have to redistribute quite a bit of credits to the users in order to align to Seti factor as we were undercrediting.

First change is already in place.
People who returns results within 24 hours will receive 50% more credits. We might adjust these values in the future.

gdf

Unless I misunderstand what you're saying, this seems to me like an ill-advised policy. It penalizes people using multi-core CPUs and encourages users to abort WUs.

Remember that reliable hosts are the one which returns results in two days and 95% success rate. These get priority.

We will try to extend the 1 day deadline as already said and to reduce the queue by matching the number of gpus.

gdf

Remember that reliable hosts are the one which returns results in two days and 95% success rate. These get priority.

We will try to extend the 1 day deadline as already said and to reduce the queue by matching the number of gpus.

gdf

LOL ... Just got this WU in by 3 Minutes or the 50% Extra Credit would have been lost. It had been finished 2 hours ealier but sat there until I manually sent it in.

I've set the Project to NNW & will have to Babysit the WU's and only get new ones as needed ...

···All my Cards are Capable of running & returning the WU's within the 24 hr period but if the Manager won't send them back in time it doesn't do any good then ...

To easy the effort, we are giving now:
60%+ for WUs returned within 1.5 days
20%+ for Wus returned within 2.0 days

We will probably also extend the deadline to 5 days for all the others.

To easy the effort, we are giving now:
60%+ for WUs returned within 1.5 days
20%+ for Wus returned within 2.0 days

We will probably also extend the deadline to 5 days for all the others.

gdf

···All my Cards are Capable of running & returning the WU's within the 24 hr period but if the Manager won't send them back in time it doesn't do any good then ...

You can activate the <report_results_immediately> option in your cc_config.xml file. If you do so, then the WUs are sent as soon as they are done.

···All my Cards are Capable of running & returning the WU's within the 24 hr period but if the Manager won't send them back in time it doesn't do any good then ...

You can activate the <report_results_immediately> option in your cc_config.xml file. If you do so, then the WUs are sent as soon as they are done.

That work for some of the Clients & some it doesn't work, I had thought of that but hadn't got around to it yet with so many other things going on.

I don't seem to be able to locate the cc_config.xml file in my BOINC folder. Is it someplace else or can one be created and put in the folder? If so how do I do it.
____________

1) Change your BOINC configuration to only use 1 CPU core. There's two ways of doing this:
1a) Use the BOINC Manager option to limit # of CPU cores to 25%, (quad-core), 33% (triple core), or 50% (dual core).
1b) Use the config file option to instruct BOINC to pretend it's a single core system. (I think this is the NCPUS flag, but I could be mistaken.)

2) Lower the work queue size to 0.1 days or similar so that BOINC never requests more than one WU.

I have a q6600 and a single 9600gso...
I am finishing work in "Approximate elapsed time for entire WU: 79329.953 s" which is about 20 hrs.

IMO this is a terrible idea. The only way a lot of us can meet this standard is to keep aborting queued WUs constantly since you insist on sending us 1 WU for every CPU instead of GPU. You're giving the fastest users a big bonus and penalizing the rest of us by burying us even further down the stats. It's already starting to cause hard feelings and negative PR is hard to overcome. You've created a very nice project, but this is a bad move (at least until you can actually provide us with a way to make it work).

The only way a lot of us can meet this standard is to keep aborting queued WUs constantly since you insist on sending us 1 WU for every CPU instead of GPU.

The problem is not really the project's fault. Until we have proper GPU support in BOINC these issues are going to be there. 6.6.20 or what ever number they give to the release version will be the first that will start to address these kinds of problems. Note I say START to address these problems. there is a lot more dificulty in Disneyland that this ...

Still, when you think of it, CUDA in BOINC is less than a year old and we have come a long way ... but there is still a long way to go ...

I'll try the method you posted on the ars forum once I clear the backlog on this machine. Until then, I just abort any "Ready to Start" GPUGRID wu's I see on the machine. It's a pain, but it works.

I agree. When I wrote the above message I was pretty irritated after spending quite a while trying to figure out why some were getting those 4900 point WUs and some weren't. Looked in the wrong forum. If I could delete the above, I would. There are ways to avoid the problem with a bit of effort.

That sounds nice.

I'd like to know, though: can any of you actually manage to reduce the queue size for GPU-Grid? What I got so far:

- BOINC 6.4.5, cache size 0.3 days -> 4 WUs (~12h each)
- BOINC 6.6.20: wanted to fetch cpu-work from GPU-Grid
- BOINC 6.5.0: cache size 0.1 day -> between 2 and 3 WUs

Ressource share for GPU-Grid is about 25% on a quad core, 1 GPU. That doesn't exactly make it easy to return results quickly..

MrS

I'm not really into this "let's award more to those that compute sooner"...

The idea behind BOINC is completely different. If you want fast computation, go get a supercomputer. If you want to use WASTED cycles, well man, you're going the wrong way.

Dario

The idea if BOINC is to help groups who can't afford a supercomputer. So saying "go get a supercomputer" just doesn't cut it.

And the point of reason for these recent adjustments is that, unlike at seti or einstein or many others, for GPU-Grid it is important to get results back quickly. Otherwise the calculations can't continue.

And adding a relatively modest bonus of 20-30% for returns within 2 days sounds very reasonable to me. Even a 9600GT can easily do this, if BOINC can be convinced not to cache the maximum amount of work. Oh, and an update on my situation: it seems like my 6.5.0 slowly starts to obey the smaller cache setting.

MrS

The idea if BOINC is to help groups who can't afford a supercomputer. So saying "go get a supercomputer" just doesn't cut it.

This is exactly the point. We are the first project which uses BOINC like if it was a supercomputer in a low-latency mode, rather that just high-throughput.
We have currently queued jobs for something like 40,000 cpus. It's impossible to get access to a supercomputer for such an amount of time.

We submit jobs, analyze the result, improve the computational protocol and re-submit again. Like if it was an experiment in a wet lab. So, we need the results fast. A paper on this usage will be out soon, where you guys can read more about our protocols.

Best, gdf.

Now this explanation makes sense of it all. If getting the results back quickly substantially helps the science, go for it. I think there'd be a lot less uproar if these kind of changes were posted along with the rational. While we like stats we're really here to help advance human knowledge. Thanks for the info.

Would reducing my resource share for GPU grid help with keeping its queue short while maintaining a longer one for my CPU, or would I just end up with an idle GPU at times because I only had CPU WUs?

Credits back to earned = granted?

No, that was just a side effect of the server being down ... no WUs were returned within the 24 hr. bonus period. I have completed and returned 4 new WUs today and have recieved the bonus :-)

Steve

The first task 522250 I received after the crash was returned well within 24 hours but received no bonus. Maybe the time is calculated from the time the task was created rather than the time it was sent??

Sorry I posted so quick based on an *assumption* that I understood the credits calculation :-(

There is definately something odd going on. It looks like the bouns is calculated for the first WU return on a Task and not what each individual WU did for a turnaround time. I found one (373949) where the original person pulled a WU on 4/7 but got bonus points based on me returning it before they did!

Yet because I forced my WUs that were waiting to be uploaded as soon as I found out the site was back up all of those made it back before they we re-issued so I get no bonus. What looks really weird is that one of these (379106) was sent to me and another individual on 4/11 (before the power outage)?
I thought all WUs were zero redundancy?

Yup, here's another example -- the original recipient's WU spanned the outage, so he didn't get bonus credit. It was subsequently sent to me -- after the first guy returned the WU -- and I got the same (non-bonus) credit as the first guy, despite my returning it in 22 hours.

Here's the WU link: 370127

Mike
____________
Want to find one of the largest known primes? Try PrimeGrid. Or help cure disease at WCG.

For this WU http://www.gpugrid.net/result.php?resultid=539356 I got less granted credit (3,460.12) than claimed credit (3,844.58). This WU was reportet in a half day and I got no bonus. Why??? Perhaps another machine (http://www.gpugrid.net/result.php?resultid=540426) reported quicker???

Kind regards

Joe

So, we have updated the new applications 6.63.
These will now claim 2x flops (seti 2.4x), but we are giving 25% bonus if you return it within 2 days. Deadline stays 5 days.

Now, if two users return the same wu, the credit with bonus is awarded to both, in case one of the two has crunched it within two days.

gdf

Speculation: I think it is a combination of many things. First, your claimed credits are higher because the change over to the base credit calculation (flops x2) happened after the first person was send their WU. Another differnce is that the app version they got was 6.62 and you got 6.63 which, besides a science update, I think also changed the bonus credit calculation from 1.5* if < 24 hours to 1.2* if < 48 hrs. Put this together with the *assumption* made by ETA above (BOINC can only handle 1 credit amount per WU) and the fact that the project needs to stream results as quick as possible makes this a tricky situation.

It looks like they are treating the WUs as Zero Redundancy (meaning they send out 1 copy of a WU and then validate and award credits as soon as it is returned). Due to the streaming nature of this project I think they they also have some optimization logic in their scheduler that determines a second copy should go out not just when ther is an error or time out, but also if the WU is the one in it's set that is holding up the assimilation to build the next batch of WUs.

In combination with the scheduling configurations, this optimzer (if it really exists) is a smart way to try and balance the deadline of 5 days with the need to stream WU sets one into another. Normally in BOINC projects when you send a second copy the first returned result gets held in PV until the wingman returns their result and consensus can be achieved. Holding WUs in PV simply does not work for this project so they process each return as if it is the only one in the WU. And once that is done, if you go back and change the awarded credits people will get upset.

So I have to ask myself, what good was this particular post? What is the project to do if the assumptions made by ETA and myself are correct? I think a deep dive into the BOINC processing / configuration is necessary and I'm not sure how much effort that would require. I don't know if the project would let me help take a look at this or if they already know all about this and for now it may simply just be the way things are but they are too polite to say so.

Gentlemen, although I have no specific BOINC experience I am a dev by trade so please let me know if I can help.
--Steve

I don't understand why i only got 2883 credits for a unit which run for 1,579.13 while another big unit gave 4804 credits for 1,497.56.
Can someone explain me why a unit running longer gets much less points

522551 25028 16 Apr 2009 1:49:24 UTC 18 Apr 2009 4:52:09 UTC Over Success Done 1,579.13 2,883.44 2,883.44

541041 388834 18 Apr 2009 4:53:29 UTC 19 Apr 2009 3:02:36 UTC Over Success Done 1,497.56 3,843.30 4,804.12

The credit calculations changed in between the two tasks. Please read above in this thread.

Steve

These are two 6.63 tasks that have given two different bonuses despite both being within 24 hours. The main difference is that one was completed on the same UTC day and the other wasn't. 537864 provided a 1.6x and 544287 was 1.25x.

537864 389455 17 Apr 2009 12:09:57 UTC 17 Apr 2009 23:21:32 UTC Over Success Done 1,131.22 3,843.30 6,149.28

544287 392874 18 Apr 2009 20:38:31 UTC 19 Apr 2009 13:55:42 UTC Over Success Done 1,218.72 3,946.78 4,933.48

I cannot see any other discernible differences. Any thoughts?

EDIT: This post by ETA answers my question.

ps. I'm getting woeful t/s scores at the moment.

Rob

I have a question!

AQUA@Home gives much more credit per hour than GPUGRID, sometimes even twice as much GPUGRID....

So Question too admins:

Are you planing to increase credit granted per WU?

It is strange that person with 9800GT can have much more credit per day in AQUA@HOME than person with GTX260 in GPUGRID....
____________
POLISH NATIONAL TEAM - Join! Crunch! Win!

AQUA@Home gives much more credit per hour than GPUGRID, sometimes even twice as much GPUGRID....

Hi!

Are points granted for this WU corret?

Sent 13 Jun 2009 17:24:29 UTC Received 14 Jun 2009 12:45:57 UTC and only Granted credit 4602.43634259259
____________
POLISH NATIONAL TEAM - Join! Crunch! Win!

I mean it should not be 5600 credits granted?
____________
POLISH NATIONAL TEAM - Join! Crunch! Win!

What the amount of demanded credit depends on?
____________
POLISH NATIONAL TEAM - Join! Crunch! Win!

I have got very long task http://www.gpugrid.net/workunit.php?wuid=547633 as second cruncher (GTX260 Top, host ID: 31329). Estimated time calculated after 4h15' (6.722%) is ~63 hours. The first cruncher's claimed credit is 45,669. I have no chance to finish it within 2 days to get bonus. On the other side claimed credit looks like bonus credit included. Now is task suspended and I’m crunching next standard 8h task to get bonus.
Question: Am I true in my calculation that bonus credit is included in that long task? If not, I will follow the first cruncher and abort that task as bonus’s looses would be about 8,700 credits during 63h run of that task.

So what to do with it, abort or try to run and finish it? I like long tasks, but if it crashes after 60h, I would not be happy.

I've got one of these monsters running too:

http://www.gpugrid.net/workunit.php?wuid=547641

3 hours, 4.5 percent done. Most normal WUs take 6-7 hours on this card.

What ever happened to that task is probably not intended.

MrS

Now I've got one of that monster Wus, too.
http://www.gpugrid.net/workunit.php?wuid=547733
26 % in 15 h. The deadline is on June 29th. Maybe imposible to finish it in time.

WhiteFire

..... I've got a pair of 'monsters' running on my 295. 24 hours elapsed and only showing 25-30% complete.

Abort or run out?

P.

I've got one of these monsters running too:

http://www.gpugrid.net/workunit.php?wuid=547641

3 hours, 4.5 percent done. Most normal WUs take 6-7 hours on this card.

Monster aborted by server, no credit granted. Moving to AQUA, it is not fair.

OK, nice

Thanks!

I agree. The whole idea of this setup is to use spare capacity NOT force people out to buy faster equipment for the sole use of these projects. My computer suits my needs not my needs be adapted to suit others.

I agree that the credit scheme should be revamped to be more fair to the volunteers.

Wiyosaya wrote:

I agree that the credit scheme should be revamped to be more fair to the volunteers.

What do you mean by that?
1. Increasing of the basic credit for short queue. That means enter to the credit war, as that credit is the same as Seti granted credit for CC 1.0/1.3 GPUs.
2. Erasing time bonus. Developers needs results ASAP, that would be not with accordance to their requirements.
3. Decreasing the basic credit of long queue to the basic credit of short queue. As I cas remember, credit bonus for long queue is for two reasons: more errors and more important results. There would be no reason to crunch the long queue if credit was the same.

I see the credit scheme by the other way: Granted credit include 24 hours bonus is the basic one and lower granted credit is penalty for slower crunching then the projets needs.

Any other idea?

I have read not only your post - I read whole thread. As you can see I have put NO response, I am asking you for response, not only for comment. I have commented possibilities that came on my mind and I am waiting for other possibilities.
It is easy to comment, it is difficult to think up. I would be happy if the credit scheme was more friendly too, but I can't see the way, what about you?

By the way - do you remember credit scheme of United Devices? If you do not: 25% of credit was according to transfer speed of a modem.