Advanced search

Message boards : News : New task on long queue from Nate, named RSP1120528

Author Message
Profile nate
Send message
Joined: 6 Jun 11
Posts: 124
Credit: 2,928,865
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwat
Message 25312 - Posted: 28 May 2012 | 16:20:08 UTC

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

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 2343
Credit: 16,201,255,749
RAC: 6,169
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25329 - Posted: 29 May 2012 | 11:33:11 UTC - in response to Message 25312.
Last modified: 29 May 2012 | 11:40:58 UTC

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.

5pot
Send message
Joined: 8 Mar 12
Posts: 411
Credit: 2,083,882,218
RAC: 0
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25331 - Posted: 29 May 2012 | 13:10:15 UTC

+1 to Zoltan's comment.

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

Profile nate
Send message
Joined: 6 Jun 11
Posts: 124
Credit: 2,928,865
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwat
Message 25332 - Posted: 29 May 2012 | 14:16:05 UTC - in response to Message 25329.

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.

Profile dskagcommunity
Avatar
Send message
Joined: 28 Apr 11
Posts: 456
Credit: 817,865,789
RAC: 0
Level
Glu
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25359 - Posted: 30 May 2012 | 15:20:58 UTC

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

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



shdbcamping
Send message
Joined: 2 May 12
Posts: 22
Credit: 145,756,579
RAC: 0
Level
Cys
Scientific publications
watwatwatwatwatwatwat
Message 25430 - Posted: 1 Jun 2012 | 20:16:36 UTC

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

Profile Carlesa25
Avatar
Send message
Joined: 13 Nov 10
Posts: 328
Credit: 72,619,453
RAC: 206
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25431 - Posted: 1 Jun 2012 | 21:21:42 UTC - in response to Message 25329.

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.


Hi: True, it has been said several times but ignored.

TheFiend
Send message
Joined: 26 Aug 11
Posts: 99
Credit: 2,500,112,138
RAC: 0
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25436 - Posted: 2 Jun 2012 | 8:29:13 UTC - in response to Message 25430.

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.

And yes, I guilty of aborting WU's.

5pot
Send message
Joined: 8 Mar 12
Posts: 411
Credit: 2,083,882,218
RAC: 0
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25449 - Posted: 2 Jun 2012 | 15:03:50 UTC

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.

Profile Bikermatt
Send message
Joined: 8 Apr 10
Posts: 37
Credit: 3,839,902,185
RAC: 0
Level
Arg
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25450 - Posted: 2 Jun 2012 | 16:04:26 UTC - in response to Message 25449.

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?

shdbcamping
Send message
Joined: 2 May 12
Posts: 22
Credit: 145,756,579
RAC: 0
Level
Cys
Scientific publications
watwatwatwatwatwatwat
Message 25464 - Posted: 3 Jun 2012 | 4:36:33 UTC - in response to Message 25436.

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

shdbcamping
Send message
Joined: 2 May 12
Posts: 22
Credit: 145,756,579
RAC: 0
Level
Cys
Scientific publications
watwatwatwatwatwatwat
Message 25465 - Posted: 3 Jun 2012 | 4:44:37 UTC - in response to Message 25450.

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?

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

MarkJ
Volunteer moderator
Volunteer tester
Send message
Joined: 24 Dec 08
Posts: 738
Credit: 200,909,904
RAC: 0
Level
Leu
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25466 - Posted: 3 Jun 2012 | 5:52:59 UTC

I think you'll find it's called CreditNew, although it doesn't handle the 24 hour bonus
____________
BOINC blog

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 670
Credit: 2,498,095,550
RAC: 0
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25467 - Posted: 3 Jun 2012 | 8:47:07 UTC - in response to Message 25332.

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.
____________
Radio Caroline, the world's most famous offshore pirate radio station.
Great music since April 1964. Support Radio Caroline Team -
Radio Caroline

Low Approach
Send message
Joined: 27 Aug 10
Posts: 9
Credit: 180,532,771
RAC: 0
Level
Ile
Scientific publications
watwatwatwatwatwatwatwat
Message 25469 - Posted: 3 Jun 2012 | 11:28:55 UTC

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?

Profile skgiven
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,995,359,260
RAC: 0
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25472 - Posted: 3 Jun 2012 | 12:39:12 UTC - in response to Message 25469.

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

HOW TO:
- Opt out of Beta Tests
- Ask for Help

wiyosaya
Send message
Joined: 22 Nov 09
Posts: 114
Credit: 589,114,683
RAC: 0
Level
Lys
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25489 - Posted: 4 Jun 2012 | 14:30:04 UTC - in response to Message 25472.
Last modified: 4 Jun 2012 | 14:36:35 UTC

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

Profile Bikermatt
Send message
Joined: 8 Apr 10
Posts: 37
Credit: 3,839,902,185
RAC: 0
Level
Arg
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25510 - Posted: 5 Jun 2012 | 16:22:32 UTC - in response to Message 25489.


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.

Snow Crash
Send message
Joined: 4 Apr 09
Posts: 450
Credit: 539,316,349
RAC: 0
Level
Lys
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25512 - Posted: 5 Jun 2012 | 17:14:15 UTC

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

Simba123
Send message
Joined: 5 Dec 11
Posts: 147
Credit: 69,970,684
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwat
Message 25684 - Posted: 13 Jun 2012 | 9:33:52 UTC

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!

Simba123
Send message
Joined: 5 Dec 11
Posts: 147
Credit: 69,970,684
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwat
Message 25689 - Posted: 13 Jun 2012 | 12:22:48 UTC - in response to Message 25684.

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!



<edit> that should be 817mb of Vram :/

also after 2 hours, now showing 12 hours to go.

TheFiend
Send message
Joined: 26 Aug 11
Posts: 99
Credit: 2,500,112,138
RAC: 0
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 25703 - Posted: 13 Jun 2012 | 20:31:52 UTC - in response to Message 25684.


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

Simba123
Send message
Joined: 5 Dec 11
Posts: 147
Credit: 69,970,684
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwat
Message 25709 - Posted: 13 Jun 2012 | 22:51:27 UTC - in response to Message 25703.


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



Just competed this task in 13 hours.
46084 GPU seconds 1371 cpu seconds for 60,900 points.

Post to thread

Message boards : News : New task on long queue from Nate, named RSP1120528

//