As announced we have deprecated the cuda3.1 application for the acemdlong queue.
The acemd2 queue stays with both applications.

From now on you should not be receiving acemdlong cuda3.1 apps.

gdf

From now on you should not be receiving acemdlong cuda3.1 apps.

Houston, we have a problem.

Your task says it was created on Dec 19th, so it should just be a leftover. Or were all existing 3.1 tasks deleted from the queue? If they were not deleted, it may be wise to remove them so that we do not end up crunching tasks that will not be used for research purposes.

Here is another problem:


http://www.gpugrid.net/workunit.php?wuid=4014336

http://www.gpugrid.net/result.php?resultid=6236277

Perhaps a project reset is required to push deprecation?
The tasks can run on either the 3.1 or 4.2app, so perhaps Boinc is controlling which app the tasks runs on locally, meaning we would need to delete the 3.1 app locally, with a project reset or an app update?

---

FAQ's

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

BTW even if crunched with previous cuda, results are still useful for research.

I did a project restart.
Let me know.

gdf

I had a look in the Boinc Projects folder and the 3.1 dll files were there.
After a project update these 3.1 files remained, but after Resetting the project they are no longer there, and hopefully wont be downloaded again.
AFAIK the tasks are sent in 3.1 or 4.2 format, so Resetting the project is not necessary, and certainly not recommended when a task is running.
The newly named app will automatically download, because the server has assigned the tasks to run on that app. It's shouldn't therefore run on the 3.1app, even if you have it.
Anyone wanting to run tasks on the 3.1app should only crunch tasks from the normal length queue, and not the Long task queue.

---

FAQ's

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

So it could be a problem when a cuda42 capable machine is in both queues? O.o

---

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

Just wasting the electricity equivalent of the cost of a premium beer today crunching three 3.1 tasks which slipped through. No doubt the boinc schedulers personality is a killjoy.

I have now created app 6.17 for cuda4.2.
It's the same application of 6.16, just a way to convince the server that cuda31 is deprecated.

gdf

...just a way to convince the server...

This made me chuckle.

Anyone care to explain what 3.1 or 4.2 is? Is it the CUDA driver version?

and now that I'm into it: what about compute capability? Most recent cards (6xx) are 3.0, how important is this version to GPUGrid?

Your questions have been covered in other threads, but I'll answer them anyway. 3.1 and 4.2 are applications that use CUDA 3.1 and 4.2 respectively. So I often refer to them as the 3.1app and 4.2app. It's actually down to the .dll files more than the CUDA version, but lets not split hairs.
The 301.42 driver is sufficient to support the CUDA 4.2 application, however some newer GeForce 600 GPU's require a more recent driver (or at least say they do).

Compute capability (CC) is just a description of each GPU's mathematical genre. These include CC1.0 (doesn't work here), CC1.1 (probably wont work), CC1.2 (might still work badly), CC1.3 (no longer efficient), CC2.0 (Fermi), CC2.1 (different generation of Fermi on which only 2/3rds of the shaders are usable for here), CC3.0 (Kepler and again only 2/3rds of the shaders are usable for here).

The CC describes the GPU's abilities, and the researchers use this to determine the GPU type. The top CC2.0 GPU's (Geforce GTX 590, 580, 570, 480, 560 Ti (448), 470, 465) are less power efficient than the top CC3.0 GPU's (GTX690, GTX680, GTX670, GTX660Ti, GTX660, GTX650Ti, GTX650) making the CC3.0 cards preferable. The GTX570 and GTX580 are roughly as powerful as the GTX660Ti, GTX670 and GTX680, but being less power efficient and an older generation they are slightly down the recommended list.

---

FAQ's

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

Dear all,

could anyone explain me why I'm getting only 3.1 normal length jobs?
Some info:

CentOS Linux 5.5
BOINC 6.10.58
CUDA Runtime 4.2.9
Driver 310.19 (just upgraded from 295.41 to test if it was the problem)

Already tried projects reset and update.....

Some hints, things to check?

Thanks in advance

Probably because all your long 4.2 tasks failed,
http://www.gpugrid.net/results.php?hostid=78927&offset=0&show_names=0&state=0&appid=23
This might have been related to your driver. I would suggest doing a project restart and restarting your system. Then select the long queue (or both) and see how you get on.

---

FAQ's

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

Probably because all your long 4.2 tasks failed,
http://www.gpugrid.net/results.php?hostid=78927&offset=0&show_names=0&state=0&appid=23
This might have been related to your driver. I would suggest doing a project restart and restarting your system. Then select the long queue (or both) and see how you get on.

Unfortunately, even after a reboot and a project reset and changing prefs to get only long jobs I'm currently not able to fetch any job.

The client reports something like "No tasks are available for the applications you have selected"

Could it be related to the quite old version of BOINC I'm running? Or to the OS?
Sorry, I'm not so good in debugging BOINC tasks...

Thanks,

So you have set your Project preferences to choose Long tasks,
http://www.gpugrid.net/prefs.php?subset=project
and presumably made sure the profile was correct for your machine.

It can take a while to start getting tasks again, but I see you have more 3.1 tasks from the 'normal' length queue.

Perhaps you need additional library files?
sudo apt-get install ia32-libs libstdc++6 libstdc++5 freeglut3

Might also be a good idea to update Boinc, especially after a driver update,
apt-get install boinc-client boinc-manager

--
I see you are now getting this error message with the Long tasks,
../../projects/www.gpugrid.net/acemd.2562.x64.cuda42: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by ./libcudart.so.4)

You have a CentOS library problem.

Came across this possible solution,
Run find / -name /lib/libc.so*

Should output something like /lib/libc.so.4 or /lib/libc.so.5 or /lib/libc.so.6

Make a soft link, ln -s /lib/libc.so.4 /lib/libc.so.6.

---

FAQ's

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

This would not probably work.

You need to install the cuda4.2 toolkit for redhat5 and set in .bashrc LD_LIBRARY_PATH to point to /usr/lib64/cuda

We distribute redhat6 libraries with the app, so you need to override our libs.

gdf

I perfectly agree, it is a problem of libraries.
Now I'm trying to solve it or I'm going to build the BOINC client from scratch

Reinstalling the server is not feasible right now

Thanks