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.

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.

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 :)

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

Nice way to alienate people from a project!

Not everybody runs high end cards and yes psome people are selective on which WU they crunch, but since it is their resources that are being donated to this project then surely it is up to them what they crunch.

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....

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?

I could easilly agree to pursue equal points/sec idea. Only problem is that the Flops mean that the per second is irrevelent. My personal take.... I like this (your) idea. I did not buy my gear for the point advantage. If this project could make this happen, I'm WAY COOL with it. it would free the long runs fron the slow down/aborts and help keep HW here it will do no harm ;)

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.

I'm sorry if this offends but if you needed it pointing out you weren't really paying attention to the user end of this project.
____________

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. Just bear in mind that it's not a race, there isn't even a finish line. There are however milestones/achievements/accomplishments.

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.
____________FAQ's

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

Sounds that simple, however, not everyone can afford big cards.

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.

However, others, including myself, find it inefficient to crunch shorter tasks because the "value" of those tasks is significantly less, as others have tried to point out.

In addition, with the current point system, there are holes that users, including myself, are unable to control. For instance, my 460 crunches some of the PAOLA WUs from the long queue in just under 24 hours, say, 23 hours actual processing time; however, due to flaky network conditions over which I have absolutely NO control, the WUs frequently fail to upload properly and require many retries, frequently putting the "return time" well over 24-hours. So even though my card completed the task in the 24 hour time frame and I should get full bonus, less credits are granted because of something over which I have no control.

In addition, someone from the project has stated that the upload data is not compressed, and my personal experience in other situations where data is transferred uncompressed is that it is more often than not problematic to transfer. Yet another issue over which no volunteer is able to do anything.

I've brought this issue about failing uploads up in several other threads, done as much as I possibly can, however, no one from the project seems to care.

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.

Perhaps, however, if what is at value here is the research, I personally think the project should consider what its volunteers are laying out whether or not people are running big cards. Without the volunteers, there would be no project. I have heard the argument that work will get done no matter who is laying out the hardware, however, I personally think that that shows a matter of inconsiderateness to all users running this project without regard to hardware.

Every one of us is making a donation to this project, some at considerable expense.

With lower credits for short-queue tasks and many volunteers not wanting to crunch them since they do not grant as much credit per run time, they will almost certainly sit longer in the queue, and that, as I see it, further increases the cost of management for those tasks. Time spent for those WUs sitting in the queue unprocessed increases their costs, IMHO.

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.

Yes, true, but consider the situation I mentioned above. I am tempted to remove that card from this project because of that even though it is well capable on other, somewhat shorter tasks.

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

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.

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.

I agree that the credit scheme should be revamped to be more fair to the volunteers. I think the project has quite a bit of input on this from its volunteers, and if the project specifically asked volunteers for more input on the matter of credits granted, a scheme more agreeable to everyone might be found.
____________

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.

Yes, this is what I was trying to say earlier.
These tasks were run on the same 570:

10,800.46 sec 8,100.00 points
32,500.30 sec 81,000.00 points

3x the run time = 10x the credit

These tasks were run on the same gt240:

72,378.51 sec 8,100.00 points
291,447.05 sec 56,000.00 points

4x the run time = 7x the credit

From a credit standpoint it isn't worth it to run the short tasks even on slow cards that do not get any bonus at all.