• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

CUDA performance

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
That's probably the BIONCStats RAC. I use the week total and divide by 7 to get the DAC. It could have changed, though, between the time we each looked at it. Updates can change DAC more radically than it changes RAC since DAC is only 7 days.

I'll try to remember to check the DAC for that rig this Sunday when I do the DAC/RAC update ... :)
 
I've seen it recommended to leave one CPU core free to "manage" the CUDA process. Is this primarily an issue with the priority of that process? Wouldn't it improve overall throughput to make that CUDA process "below normal" instead of "low" while still using all cores? I assume BOINC does not dedicate a core to this CUDA process. But, if it just gave it CPU time when needed, it should run nearly as fast as if it had a dedicated core.

I could likely write a service that would simply monitor for this process and change the priority when it finds that process out there.

Thoughts?

Because the video card cannot upload the whole work unit and crunch it on its own for the CUDA process data needs to be constantly feed to the video card. If the processor is busy crunching a seti@home unit then it might not always be free to send that data to the video card thus creating a "lag time" in processing until a few cpu cycles are available. This would not be an issue if the video cards are not that effiecent (i.e. my 8600 GTS with only 32 shaders). However, high power cards can crunch work units in under 5 minutes thus that "lag time" adds up to many more work unit. It would take your CPU much longer to crunch the same work unit.

My general rule is leaving one CPU core open for each "High End" video card I have in my system. Currently, I am running an X4 940@Stock with only 1 core crunching Seti@home, while the other three feed my graphics cards.

CPU0 = Seti@home
CPU1 = 285 GTX @ 720/1620/1390
CPU2 = 260 GTX @ 680/1466/1050
CPU3 = 260 GTX @ 742/1595/1050

Hope this info helps.
 
Well, my EVGA GTX-260 superclocked edition arrived today. I will have it crunching by bedtime ;-) Shooting for 15K RAC from this rig...
BTW, Sir-Epix...those are some nice clocks you have going on those cards :shock:
 
Well, I'm stumped. I simply cannot get BOINC to request GPU units for SETI.

It does recognize it:
4/7/2010 9:56:43 PM NVIDIA GPU 0: GeForce GTX 260 (driver version 19713, CUDA version 3000, compute capability 1.3, 877MB, 616 GFLOPS peak)

But when it requests work, all I get are CPU requests:

4/7/2010 10:23:43 PM SETI@home Sending scheduler request: To fetch work.
4/7/2010 10:23:43 PM SETI@home Requesting new tasks for CPU
4/7/2010 10:23:48 PM SETI@home Scheduler request completed: got 0 new tasks
4/7/2010 10:23:48 PM SETI@home Message from server: (Project has no jobs available)
4/7/2010 10:24:04 PM SETI@home Sending scheduler request: To fetch work.
4/7/2010 10:24:04 PM SETI@home Requesting new tasks for CPU
4/7/2010 10:24:09 PM SETI@home Scheduler request completed: got 0 new tasks
4/7/2010 10:24:09 PM SETI@home Message from server: (Project has no jobs available)

I have seen it request GPU units for World Community Grid, but they don't use the GPU.

Using the "Update" button has no effect. I even tried upping the # of days in preferences, to no avail.

I guess I will let it run, and see if it eventually requests GPU work.

Any ideas?
 
OK, Fixed, I think. Why is it that whenever I add new hardware there are no tasks available?

Make sure you have the option clicked on your Preference's @ Seti@home's website. If you don't have it enabled there you will never get work. However, you are correct that last night there was no work available.
 
Once again it is not even trying to request work for the GPU. All I see are CPU requests. I think I'm doomed to never crunch on the GPU...

EDIT: I don't know...I'm so confused...

OK, it's clearly requesting GPU tasks now (and did overnight--I just didn't see it). So, I just have to wait until there are some available. They have been trickling in this morning, so maybe I'll get some to crunch later on.
 
Last edited:
Well, I'm happy to report that I'm happily crunching CUDA units.

Let me try to clarify what I was discussing about priority of the tasks. The main reason you need to leave a core free for CUDA units is that the process managing them (MB_6.08_CUDA...exe) is set to run at the same priority as the rest of the crunchers. So when it needs CPU time, it has to share it with the other crunchers, which slows it down.

I've elected to try a different route--I'm using Process Lasso to automatically set the priority of that process to Below Normal, which will give it all the CPU it needs (so it doesn't have to "share" with the crunching processes). I believe this will allow for higher overall throughput since most of the time, this process is only using about 1/6 of a core (except at startup when it uses a lot more--but by setting the priority, it is using 100% of a core).

I will report back in a few days with results, but I think they will be good.
 
That's one of those programs that will grab it when the process starts and give it your pre-set priority, right? I played with one of those (not for CUDA) awhile back and it seemed to work pretty good for what I was doing. I'll be interested to see how it works with CUDA - so post back in a week or so and let us know ...! :)
 
That's one of those programs that will grab it when the process starts and give it your pre-set priority, right? I played with one of those (not for CUDA) awhile back and it seemed to work pretty good for what I was doing. I'll be interested to see how it works with CUDA - so post back in a week or so and let us know ...! :)

Yes, you're absolutely correct. I noticed that the process tries to set itself back to idle a second time, but Process Lasso has a setting to monitor and reset if necessary. Seems to be working great so far.

On a side note, I was able to overclock this GTX-260 to 720 core with seemingly no glitches; 750 caused a system hang. I will likely run it in the 680 range for awhile to see how things work. Nice card from EVGA...I think it's worth the few extra bucks as they are essentially guaranteeing a nice overclock.
 
I have one more question, and I'm sure there's a quick fix, but I don't know where it might be. I ran out of Cuda units last night, mainly because BOINC is underestimating how much work my GTX-260 can do by a factor of 10. Blocks that it thinks take 2.5 hours are taking 15 minutes. As a result, it is not queueing nearly enough work to weather any kind of outage. Is there an easy way to have BOINC calculate this more accurately?

Thanks in advance...
 
There was a way but I don't know if it works with newer versions of BOINC. Let me see if I can find the thread where we talked about that ...


Edit
I didn't read through all of it but Duner goes into the p_flops thing in post #7 and that's what I was thinking about. Like I said, though, not sure it's the right thing for newer apps but it's worth a try ... :)

http://www.overclockers.com/forums/showthread.php?t=618834
 
Thanks. I've made the suggested change, so now it's a waiting game to see if the estimated time of the blocks is more accurate and it queues up the correct amount of WUs.

I managed to grab a few cuda blocks, and the estimated times are MUCH closer to reality now. The line I used was:

<flops>100e+9</flops>

in the <app_version><setiathome_enhanced> area.
 
I've got the final numbers in

GTX 260 192sp @ 602/1296/1023 core/shader/mem does.............10500 RAC for the last 4 days. This is up from 6000 RAC from a higher clocked 192sp card. The only change was stopping Rosetta on the CPU and the RAC shot up like a rocket.

I also had a 9600GT on this rig. That's 64sp @ 675/1650/900 core/shader mem and it did 3000 RAC. Again, this is with the CPU idle.

Here's a shot of my GTX 260 in action. Too bad I'm going to switch it over the Folding for a while. I was just waiting for the RAC to stabilize before changing it over.
 

Attachments

  • Boinc.jpg
    Boinc.jpg
    152.5 KB · Views: 733
Back