To provide a reference I'm running now one task at a time and no CPU tasks.
I have one RTX2080Ti, one Titan V, and two GTX 1080 GPU cards.
I have set my settings to accept those great awarding +3800? credit tasks and if they are not available then accept other.
...
The server sends me those 1000 credit (graviational search) tasks and an occasional +3800 credit one.
...
I have thinkered and thankered something to the OpenCL code with LD_PRELOAD and some creative coding but I'm totally lost in timespace if I have done something right or totally wrong. I have no idea what the run times for Gravitational search with Nvidia GPU's should be when running one at a time.
The GR or Gamma Ray gpu tasks award 3465 fixed credit. Historically run 8-10 minutes on RTX 2080, GTX 1080 Ti etc. Though the current series has a lot cranking through in under 5 minutes.
The GW tasks typically run around 6-8 minutes though we did have a one-off series a month ago that only needed 4-6 minutes to run on my hardware. The Gravity Wave award 1000 fixed credits for the gpu tasks.
It is difficult to run both gpu tasks at the same time.
Pick one or other. Nothing else seems to work well.
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
The server sends me those 1000 credit (gravitational search) tasks and an occasional +3800 credit one.
If you allow both GPU searches, you will tend to get more GW tasks because I believe the server has a builtin mechanism to prefer to send GW tasks when both are allowed. It does happen (very rarely) that one particular type might be temporarily unavailable but most people find that they can set just the search they want to support (for whatever reason) without having to worry too much about a rare unavailability of work.
Many years ago (before there was a GPU app) the GRP CPU search awarded 693 credits. When the GRP GPU app was first released (from memory nearly 10 years ago) the tasks for it were a bundle of 5 CPU tasks. The credit award was set at 693x5 = 3465. The work content remained much the same but app efficiency improved over the years and the credit remained unchanged.
Tasks for the LATeah3000 series (in particular) run faster than the more 'traditional' offerings. I'm guessing that for some reason they have a lower work content but no change was made to the credit award when they first were issued. Perhaps there should have been a commensurate reduction. I expect that at some point this will change back to longer running tasks, but there has been no announcement explaining the change or if/when it might revert. Enjoy the current fast running stuff while it lasts :-).
GW GPU tasks are designed to have the same work content as GW CPU tasks - hence the same credit. A lot of the work in a task can't be parallelised, hence the much heavier CPU involvement and lower GPU utilisation when running GPU tasks.
petri33 wrote:
I have thinkered and thankered something to the OpenCL code with LD_PRELOAD and some creative coding but I'm totally lost in timespace if I have done something right or totally wrong. I have no idea what the run times for Gravitational search with Nvidia GPU's should be when running one at a time.
I'm not sure what the above is supposed to mean but if tasks are running without error then you have a viable OpenCL setup and there's probably nothing more to change that would make a significant improvement to run times. I don't use nvidia at all but many others who do have noted that there's no real improvement (perhaps a regression) by attempting multiple concurrent tasks.
If you just compare your run times with what your quorum partners are getting (very likely many are running just single tasks) you're bound to find some nvidia GPUs similar to your own for a comparison.
For what it's worth, on an older, mid-range AMD GPU (RX 570), current GRP GPU tasks (LATeah3000 series) take about 6.5 min per task when run at x2 multiplicity (2 tasks in around 12 to 13 mins). It's around 8 mins when run as singles.
For current GW GPU tasks on an 8GB RX 570, I run either x3 or x4 depending on the DF value - delta frequency or difference frequency visible in the name of a task. Tasks that can run efficiently at x3 have a run time of around 8 - 10 mins per task (3 tasks in the 24 to 30 mins range) whilst x4 tasks take about 5 - 7.5 mins per task (4 tasks in 20 to 30 mins range). These are all substantial improvements on running singles, hence my willingness to experiment with the optimum combination of multiples :-).
To run multiples efficiently, a decent CPU with lots of free cores is important. Each person really needs to work out the best combination for their particular setup. You cannot just rely on what somebody else uses.
I run all tasks with DF greater than 0.6Hz at x3 and those below that value at x4. This changeover point seems to work OK for my setup at the moment but I'm expecting that it may change over time as the analysis frequency steadily increases.
For me, the current analysis frequency (the 2nd value in the task name) is in the 700Hz to 800Hz range and has been steadily rising over the last several months. Based on previous searches, it could eventually reach as high as close to 2000Hz - or it could be totally different this time. There has been no official word so I just keep an eye on things occasionally. Things have been pretty steady for a while lately.
Many years ago (before there was a GPU app) the GRP CPU search awarded 693 credits. When the GRP GPU app was first released (from memory nearly 10 years ago) the tasks for it were a bundle of 5 CPU tasks. The credit award was set at 693x5 = 3465. The work content remained much the same but app efficiency improved over the years and the credit remained unchanged.
again, credit here is based on the estimated flops that the project has set, and that propagates out to things other than just credit reward (like DCF). they didnt take the 693 value and scaled it by 5, they took the flops and scaled it by 5. don't misunderstand what's actually happening or the mechanism at play.
Gary Roberts wrote:
petri33 wrote:
I have thinkered and thankered something to the OpenCL code with LD_PRELOAD and some creative coding but I'm totally lost in timespace if I have done something right or totally wrong. I have no idea what the run times for Gravitational search with Nvidia GPU's should be when running one at a time.
I'm not sure what the above is supposed to mean
[redacted by moderator] petri is a developer and he's been granted the source code from the project developers. he can play with code and compilation options at his leisure. for context, he's responsible for the bulk of the code which sped up SETI processing speed by several times with his special CUDA application.
petri, now that this "rare" occurrence has come upon us, and GR tasks are out, i've failed over to GW tasks and will compare my 2080ti runtimes to yours. I'll PM you to talk about some code changes you implemented and I can try them out too.
Hi Ian&Co and others, To
)
Hi Ian&Co and others,
To provide a reference I'm running now one task at a time and no CPU tasks.
I have one RTX2080Ti, one Titan V, and two GTX 1080 GPU cards.
I have set my settings to accept those great awarding +3800? credit tasks and if they are not available then accept other.
...
The server sends me those 1000 credit (graviational search) tasks and an occasional +3800 credit one.
...
I have thinkered and thankered something to the OpenCL code with LD_PRELOAD and some creative coding but I'm totally lost in timespace if I have done something right or totally wrong. I have no idea what the run times for Gravitational search with Nvidia GPU's should be when running one at a time.
--
petri33
The GR or Gamma Ray gpu tasks
)
The GR or Gamma Ray gpu tasks award 3465 fixed credit. Historically run 8-10 minutes on RTX 2080, GTX 1080 Ti etc. Though the current series has a lot cranking through in under 5 minutes.
The GW tasks typically run around 6-8 minutes though we did have a one-off series a month ago that only needed 4-6 minutes to run on my hardware. The Gravity Wave award 1000 fixed credits for the gpu tasks.
All times are for singletons on any card.
It is difficult to run both
)
It is difficult to run both gpu tasks at the same time.
Pick one or other. Nothing else seems to work well.
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
Tom M wrote: It is difficult
)
My GTX1660S does not mind but I do try to run GWs as much as possible.
Both tasks will run, but the
)
Both tasks will run, but the dissimilar DCF for each task type causes the host to monopolize one over the other with respect to job fetch.
You need to absolutely run with as small a cache as possible to not overfetch work.
petri33 wrote:The server
)
If you allow both GPU searches, you will tend to get more GW tasks because I believe the server has a builtin mechanism to prefer to send GW tasks when both are allowed. It does happen (very rarely) that one particular type might be temporarily unavailable but most people find that they can set just the search they want to support (for whatever reason) without having to worry too much about a rare unavailability of work.
Many years ago (before there was a GPU app) the GRP CPU search awarded 693 credits. When the GRP GPU app was first released (from memory nearly 10 years ago) the tasks for it were a bundle of 5 CPU tasks. The credit award was set at 693x5 = 3465. The work content remained much the same but app efficiency improved over the years and the credit remained unchanged.
Tasks for the LATeah3000 series (in particular) run faster than the more 'traditional' offerings. I'm guessing that for some reason they have a lower work content but no change was made to the credit award when they first were issued. Perhaps there should have been a commensurate reduction. I expect that at some point this will change back to longer running tasks, but there has been no announcement explaining the change or if/when it might revert. Enjoy the current fast running stuff while it lasts :-).
GW GPU tasks are designed to have the same work content as GW CPU tasks - hence the same credit. A lot of the work in a task can't be parallelised, hence the much heavier CPU involvement and lower GPU utilisation when running GPU tasks.
I'm not sure what the above is supposed to mean but if tasks are running without error then you have a viable OpenCL setup and there's probably nothing more to change that would make a significant improvement to run times. I don't use nvidia at all but many others who do have noted that there's no real improvement (perhaps a regression) by attempting multiple concurrent tasks.
If you just compare your run times with what your quorum partners are getting (very likely many are running just single tasks) you're bound to find some nvidia GPUs similar to your own for a comparison.
For what it's worth, on an older, mid-range AMD GPU (RX 570), current GRP GPU tasks (LATeah3000 series) take about 6.5 min per task when run at x2 multiplicity (2 tasks in around 12 to 13 mins). It's around 8 mins when run as singles.
For current GW GPU tasks on an 8GB RX 570, I run either x3 or x4 depending on the DF value - delta frequency or difference frequency visible in the name of a task. Tasks that can run efficiently at x3 have a run time of around 8 - 10 mins per task (3 tasks in the 24 to 30 mins range) whilst x4 tasks take about 5 - 7.5 mins per task (4 tasks in 20 to 30 mins range). These are all substantial improvements on running singles, hence my willingness to experiment with the optimum combination of multiples :-).
To run multiples efficiently, a decent CPU with lots of free cores is important. Each person really needs to work out the best combination for their particular setup. You cannot just rely on what somebody else uses.
I run all tasks with DF greater than 0.6Hz at x3 and those below that value at x4. This changeover point seems to work OK for my setup at the moment but I'm expecting that it may change over time as the analysis frequency steadily increases.
For me, the current analysis frequency (the 2nd value in the task name) is in the 700Hz to 800Hz range and has been steadily rising over the last several months. Based on previous searches, it could eventually reach as high as close to 2000Hz - or it could be totally different this time. There has been no official word so I just keep an eye on things occasionally. Things have been pretty steady for a while lately.
Cheers,
Gary.
Gary Roberts wrote:Many
)
again, credit here is based on the estimated flops that the project has set, and that propagates out to things other than just credit reward (like DCF). they didnt take the 693 value and scaled it by 5, they took the flops and scaled it by 5. don't misunderstand what's actually happening or the mechanism at play.
[redacted by moderator] petri is a developer and he's been granted the source code from the project developers. he can play with code and compilation options at his leisure. for context, he's responsible for the bulk of the code which sped up SETI processing speed by several times with his special CUDA application.
petri, now that this "rare" occurrence has come upon us, and GR tasks are out, i've failed over to GW tasks and will compare my 2080ti runtimes to yours. I'll PM you to talk about some code changes you implemented and I can try them out too.
_________________________________________________________________________