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

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

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

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

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

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

To prevent receipt of tasks from either queue, when editing your Project Preferences unselect the following,

If no work for selected applications is available, accept work from other applications?

This is usually not required as the queues are normally loaded with plenty of tasks. However application testing is presently under way.
____________
FAQ's

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