Hey everyone,

I have submitted some new tasks to the long queue. This is a new system that hasn't been run before on The Grid, but since I'm not doing anything new configuration wise, I don't expect any problems. These will be higher priority tasks than most, and if all goes well we hope to get some positive results quickly. I'll elaborate on the goal of these simulations later. They should run for about 7 hours on the fastest cards. I'll be keeping a close eye on them over the next few days, but please report any problems when you see them.

Nate

My first workuint from this batch is finished in 7h 20m on a GTX 480@800MHz. 60.900 credits were granted. I think GPUGrid should grant credits for a workunit in direct ratio of it's running time (plus bonus for the fast return), not the estimated flops to avoid selective abortions of less rewarded workunits. Another example.

+1 to Zoltan's comment.

Also, nice job with these tasks, they're running at 89% on W7

RZ, thanks for pointing it out. The discrepancy seems quite extreme in some of those cases, and perhaps there is a human error or an error in the algorithm. It certainly shouldn't be so much, so we are looking at it. Stay tuned.

Computing the third one of them and no Problems at all.

13,2h on 285GTX
____________
DSKAG Austria Research Team: http://www.research.dskag.at

Selective abortions of projects should be met with directed deletion from the long project pool. JIMO.
The project should be able to come up with a failure or error percent to deal with it. Personally, I don't see enough difference in anything assigned me so far to even warrant that much of my time on long projects :)

My first workuint from this batch is finished in 7h 20m on a GTX 480@800MHz. 60.900 credits were granted. I think GPUGrid should grant credits for a workunit in direct ratio of it's running time (plus bonus for the fast return), not the estimated flops to avoid selective abortions of less rewarded workunits. Another example.

Selective abortions of projects should be met with directed deletion from the long project pool. JIMO.

Long runs are for people with high end cards though. If you don't have a high end, and you don't want your card to crunch for days to complete one. That's exactly what the short queue is for.

Long runs are for people with high end cards though. If you don't have a high end, and you don't want your card to crunch for days to complete one. That's exactly what the short queue is for.

Just saying that we as donors should care enough to make sure that we don't delay research in the hunt for points. if we care for the project, let it go. if you can't run long units efficiently on your HW. Please don't check that box. Every aborted project WU takes time to reassign and slows the project results.
I only upgrade my HW when/if I can but only to enable myself to provide a higher level of support to projects that I care about.
Personally, I feel there should be no difference in points. But then how can/could we justify that when the flops of HW are so diverse?
I don't want to cause a stir....

Long runs are for people with high end cards though. If you don't have a high end, and you don't want your card to crunch for days to complete one. That's exactly what the short queue is for.

Unfortunately if you compare the credit granted per second of GPU time for the long versus short task you will notice the short tasks grant 2-3 times less credit for the amount of time crunched.

Here is an example: http://www.gpugrid.net/results.php?hostid=98879

This is why people run the long tasks on slower cards. If the short tasks paid better more people would crunch them.

If the credit granted is based on the work done during the task is this credit discrepancy due to short tasks not doing the same amount of work per second or is it due to how the bonus is calculated?

RZ, thanks for pointing it out. The discrepancy seems quite extreme in some of those cases, and perhaps there is a human error or an error in the algorithm. It certainly shouldn't be so much, so we are looking at it. Stay tuned.

The decision was made to have a points system, for the fun of competing users and the benefit of the project.

To me it defies the whole idea of competition when users are rewarded for aborting specific workunits, or only crunch WUs from the long queue. This kind of advantage results from using the more rewarding jobs only and leaving the less rewarding ones to the others.

That being said, I understand how the current system is supposed to value the actual calculations being done. Slower cards should give less credit, alright. They usually require less power, too.

However, the competitive people here are comparing overall credit and RAC, which is credit/time, so they want their GPUs to be utilized as much as possible. Guess why there is so much talking about overclocking and cooling issues. A race driver wants to finish first, not to hear "yeah, you've finished fourth, but think about all the fuel you've saved by driving slower."

With that in mind I wish that I wouldn't have to frown anymore whenever I see a an EKObis or MJH job in my queue, knowing that they all give almost the same amount of points per hour. Actually, ACEMD-jobs from the short queue would also be nice, but as was pointed out before, they're just not competitive credit/time-wise.

What I'm wondering though: Is the runtime relation of different types of WU the same on different hardware? In other words: let's say I've found the NATHAN_RPSs are giving 32% more credit/hour than the MJHs on my GTX 570, would that ratio be the same on other cards? And if not, by how much are they varying?

If credit is that important to anyone, then get a big card and crunch long tasks.

I suggest people with Big cards also crunch some of the shorter tasks, at least on occasion, so as to participate in any of the research that only appears in the short queue, and in doing so get recognition (Participation badges linking to scientific publications). I find this more meaningful than credits.

Anyone unhappy about the credit for the short tasks should consider the expenses. The outlay and running costs are significantly higher for a big card than a low or mid range card. Also consider that there is a greater server hardware requirement for the short tasks and more time is needed to maintain the queue. More maintenance tends to mean less time for research.

A reasonable mid-range card can still get more credit for completing long tasks, even if they can't always finish <1day. From one day to two days still gets a 25% bonus.

The short tasks enable crunching on lesser cards and by non 24/7 crunchers.

Going back to the original topic, several releases of tasks required an alteration to the credit, so perhaps the system used needs to be rethought or implemented better.

IMHO, this project is one that requires 24/7 crunching even on short tasks because in some cases, say getting a short-queue WU, crunching it a bit, shutting down the computer and then restarting calculation 24 or more hours later, you don't have the bonus.

And that short-queue tasks are less-valued by the project evidenced by the fact that the project gives significantly less credits for crunching them invites, IMHO, volunteers to not crunch them, which means that those results will take longer to get

Whether the project likes it or not, the "bonus" will cause uses to the chase credits that the project gives - as I see it.

Hi Nate - just to let you know I'm crunching my ascii off on these WUs :thumbsup:

I encourage everyone to chase points and have some fun ... abort all you want, my old GTX295 will crunch 'em!
____________
Thanks - Steve

Ah, the old points race argument raises its' head.
No-one (project leaders or donors) can win that argument; someone is always going to be unhappy. That is all I have to say on that.

On topic, the Nathan RPS1120528 units. Just fired up my first one and wowza!
I'm actually seeing 96% GPU load on a Win7 Box :) nice.
Using 817Mb of ram too.

Showing 17 hours to complete on my 560ti @900/1800/2004.

Seems pretty good to me!

Ah, the old points race argument raises its' head.
No-one (project leaders or donors) can win that argument; someone is always going to be unhappy. That is all I have to say on that.

On topic, the Nathan RPS1120528 units. Just fired up my first one and wowza!
I'm actually seeing 96% GPU load on a Win7 Box :) nice.
Using 817Mb of ram too.

Showing 17 hours to complete on my 560ti @900/1800/2004.

Seems pretty good to me!

On topic, the Nathan RPS1120528 units. Just fired up my first one and wowza!
I'm actually seeing 96% GPU load on a Win7 Box :) nice.
Using 817Mb of ram too.

Showing 17 hours to complete on my 560ti @900/1800/2004.

Seems pretty good to me!

On topic, the Nathan RPS1120528 units. Just fired up my first one and wowza!
I'm actually seeing 96% GPU load on a Win7 Box :) nice.
Using 817Mb of ram too.

Showing 17 hours to complete on my 560ti @900/1800/2004.

Seems pretty good to me!

That might explain why my GTX460 768MB is only managing similar run times to my GTX550Ti 1GB with these RPS units. :(