Hi guys,

I'd really love to crunch for you but I'm the owner of a not-so-fast GPU (GT 440) and even though I've only selected the short WUs in my preferences, the reporting deadline is just not enough for me. Maybe extend it with 2 more days and I'll be happy. I also GPU crunch on other projects (PrimeGrid, M@H, E@H, etc) and after a few "experiments" trying to crunch for GPUGRID, I see I barely can report in time...

And I don't want to hear "buy a faster card" as my budget doesn't allow it. Is there really a reason for such short deadlines?

To follow up a bit on it, could this be my problem for WUs taking so long? The GT 440 has 96 cuda cores, while the GPUGRID seems to think it only has 16, if I'm interpreting this correctly

# There is 1 device supporting CUDA
# Device 0: "GeForce GT 440"
# Clock rate: 1.64 GHz
# Total amount of global memory: 1073283072 bytes
# Number of multiprocessors: 2
# Number of cores: 16

GPUGRID needs short deadlines because new work units are generated from the results of the previously completed work units. The faster work units are completed, the quicker the GPUGRID team can investigate the target research, whether it be protein simulation/drug binding etc. If your budget doesn't allow for anything greater than a GT440, then unfortunately GPUGRID really isnt't the project for you (unless the devs have something planned for the future).

If you don't have any loyalty to the BOINC framework, you should really try folding@home, where the GT440 gets very respectable numbers for the $ and watt.

Regards

To follow up a bit on it, could this be my problem for WUs taking so long? The GT 440 has 96 cuda cores, while the GPUGRID seems to think it only has 16, if I'm interpreting this correctly

I think what's happening is that the GPUgrid application can use only 16 of the 96 cores due to the GT 440's architecture or compute capability. You can probably find other projects that have apps that can use all of your 96 cores.

To follow up a bit on it, could this be my problem for WUs taking so long? The GT 440 has 96 cuda cores, while the GPUGRID seems to think it only has 16, if I'm interpreting this correctly

I think what's happening is that the GPUgrid application can use only 16 of the 96 cores due to the GT 440's architecture or compute capability. You can probably find other projects that have apps that can use all of your 96 cores.

GPUGrid can use only the 2/3 of the cuda cores of CC2.1 cards (in your case 64), regardless of this reporting bug (the number of cores always equals 8 times the number of multiprocessors, regardless of the real ratio, which is 48 for CC2.1 cards, and 32 for CC2.0 cards)

Thanks for the reply, guys :)

I'm currently eyeing a GTX 560 from ASUS. Though I only have a 450W power supply in my cruncher. Not sure if that'll be enough for it...

When its not a no name PSU then it will be no problem. This card does not take that much. About 150W

---

DSKAG Austria Research Team: http://www.research.dskag.at

Guys, if you look at the run times for microchip's tasks you will see that the card could finish ~2.6tasks per days. You would also see the tasks were started and stopped many times.

From microchip's project list, you can see he crunches for about 5 or 6 other GPU projects, and if you go to them you can see microchip does this on the same system. So the problem is running more than one GPU project; the projects aliquot of time, compounded by the 'switch between applications' setting and cache levels means the tasks are stopped and started repeatedly.

Newcomers with similar systems should use recommended settings, such as keep a low cache, don't crunch on multiple GPU projects with entry level GPU's, report tasks immediately, and set 'switch between applications' to a high number (Use 900minutes, as this is longer than the time that system would take to complete a normal length GPUGrid task).

microchip, although it's not the fastest it's far from useless, and a GT 440 (96 cuda core version) has a 45W TDP. Even the 144cuda core versions only has a 69W TDP.

If you want to upgrade some time, then get a CC2.0 GPU and a good PSU. Until then configure your system to crunch here.

Thanks for the reply, skgiven :)

Yes, I also crunch on the GPU for 3 other projects (Einstein, Milkyway and PrimeGrid) so with GPUGRID in it, I have 4 projects on the GPU. My cache setting is set to 0 so it should report results immediately. I haven't touched the "switch between applications" option so it is currently set at 60 minutes. I'll increase it as suggested

My cache setting is set to 0 so it should report results immediately

It will download new task only when the current one finished. Uploading finished tasks is not the same as reporting them. Reporting results takes place once per day by default, so you might miss a bonus at GPUGrid, if you finish a task just in 24h (or 48h), but don't report it immediately.
You should make a cc_config.xml simple text file (if you don't have one already) to the working directory of BOINC, and paste the following lines in it:
<cc_config>
<options>
<report_results_immediately>1</report_results_immediately>
</options>
</cc_config>
Then save it, and restart BOINC manager.

My cache setting is set to 0

Create the cc_config.xml as Retvari suggested.

Also, your statement that your cache is 0 isn't absolutely clear so I offer the following suggestion just to make sure. The cache is governed by 2 settings. The "Connect about every__days" should be 0 and the "Additional work buffer__ days" should be very small, I use 0.1.

My cache setting is set to 0

Create the cc_config.xml as Retvari suggested.

Also, your statement that your cache is 0 isn't absolutely clear so I offer the following suggestion just to make sure. The cache is governed by 2 settings. The "Connect about every__days" should be 0 and the "Additional work buffer__ days" should be very small, I use 0.1.

both of these are set to 0 here and I already have the cc_config.xml file with the setting to report immediately. I made that file 5 days ago, but even when I didn't have it, BOINC reported them immediately after finishing with crunching. This is for version 6.12.34. While I was on version 6.10.58, it did not report them immediately so something changed in 6.12.34

Some news...

My last WU took 34 hours to compute on the GT 440. I barely made it and was actually 5 minutes over the deadline (which was set at 19:45 CEST) and I reported at 19:50. Luckily I did get the credit. I've no idea why I got it as I was full 5 minutes late in reporting. Still nice to have it, though :)

The stderr output for that 34 hour task shows you're not using swan_sync=0 and the task seems to have restarted repeatedly. Did it get preempted repeatedly by other projects or did it run uninterrupted? If you set the "switch between tasks every..." to 900, the task should run 15 hours without being preempted, unless you have other tasks that go to high priority mode. Any high priority tasks?

Put "export SWAN_SYNC=0" in your .bashrc file so it initializes SWAN_SYNC every time you boot and then run that command in a terminal to initialize it for the current session. Then exit BOINC client and restart it to restart the task with SWAN_SYNC=0. Some say it makes no difference, others claim it does.

You allow BOINC to use all 6 of your cores. So then you have 6 CPU tasks running plus the GPU task, right? Try allotting BOINC only 5 cores so that 1 core is free to service the GPU. To do that set "On multiprocessor systems use at most..." to 83%. That might decrease your run times too.

Hey Dagorath

Yes, I have SWAN_SYNC=0 in my bashrc, but I haven't rebooted yet so I shall initialize it now and restart boinc. About freeing one CPU core, I don't think that'll make a difference as the Linux scheduler switches tasks dynamically between different cores - it doesn't lock a task to a single core for the whole time. I also set the "switch between applications" to 10 hours instead of 15. And no, there were no high-priority tasks running on the GPU

Hey Dagorath

Yes, I have SWAN_SYNC=0 in my bashrc, but I haven't rebooted yet so I shall initialize it now and restart boinc. About freeing one CPU core, I don't think that'll make a difference as the Linux scheduler switches tasks dynamically between different cores - it doesn't lock a task to a single core for the whole time. I also set the "switch between applications" to 10 hours instead of 15.

I think all modern OS kernels do that, to support all the other background multitasking that goes on.

"Free a core" is just a conventional shorthand for "reduce the CPU loading", to make it more responsive for servicing the sync tasks.

Some say it makes no difference, others claim it does.

SWAN_SYNC makes a difference (improves performance) for Fermi cards on Linux:
SWAN_SYNC was specifically designed for Fermi cards and works better on the 6.14 app (used with Linux).
For the 6.15 app used with Windows with a Fermi, SWAN_SYNC still improves performance a little, but with just a small gain (on average) the expense of losing a CPU core/thread is not worth it for some, and might reduce system responsiveness (more noticeable on lesser cards).

---

FAQ's

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