Aborting CUDA3.1 tasks are easy (also detrimental for the project), but what can you do if you have a CUDA3.1 workunit running for hours, and you don't want to waste it?
I've figured it out, that I can convert CUDA3.1 tasks to CUDA4.2 tasks.
So if you have some file management skills, you can do it too in no time:
(My instructions are for Windows only) V2.0

1. Pause all running CUDA3.1 tasks in BOINC manager
2. Locate the slot directory of the CUDA3.1 task by searching through the slots for the CUDA3.1 executable (acemd.win.2352)
---(on Windows XP the slots are located in c:\Documents and Settings\All Users\Application Data\BOINC\slots\)
---(on Windows 7 the slots are located in: c:\ProgramData\BOINC\slots\)
3. Copy the CUDA4.2 executable files to the slot directory of the CUDA3.1 task located in step 2.
---(the source of the CUDA4.2 client files (acemd.2562.cuda42, cudart32_42_9.dll, cufft32_42_9.dll) is:)
---(on Windows XP: c:\Documents and Settings\All Users\Application Data\BOINC\projects\www.gpugrid.net\)
---(on Windows 7: c:\ProgramData\BOINC\projects\www.gpugrid.net\
4. Delete the CUDA3.1 client (acemd.win.2352) from the directory located in step 2.
5. Rename the CUDA4.2 client executable file to the name of the CUDA3.1 client in the slot directory
---(acemd.2562.cuda42 -> acemd.win.2352)
---(do not rename the dll's)
6. Rename the CUDA3.1 client executable file in the project directory. (acemd.win.2352 -> acemd.win.2352.bak)
---(on Windows XP: c:\Documents and Settings\All Users\Application Data\BOINC\projects\www.gpugrid.net\)
---(on Windows 7: c:\ProgramData\BOINC\projects\www.gpugrid.net\
7. Make a copy of the CUDA4.2 client in the project directory, and rename it to the CUDA3.1 client's name. (copy of acemd.2562.cuda42 -> acemd.win.2352)
8. Restart the CUDA3.1 tasks in BOINC manager (they will be displayed still as a CUDA3.1 task)

I hope it will work for you too.
Windows Explorer should be set to show hidden and system folders if you want to browse for these directories, or you can paste the paths directly from my text.
Also the "hide extensions of known files" option should be disabled.
I recommend a file manager tool like Total Commander (step 4 and 5 can be done in a single step with this utility)
I ask a Linux expert to try a similar method, and share it here if it's working on Linux too.

Hopefully this will not impact on the building of subsequent tasks?

I will try your workaround if I get any more CUDA 4.2 tasks on Windows, but I fully expect it to work.

Am I correct in that you need to do this every time you notice a cuda3.1 WU running?

Very cool that this appears to work, but quite a bit of monitoring of the system.

Nice work Retvari!!!

I had been thinking along these lines or maybe using a appinfo.xml to pull a switcheroo but thank you very much for working through the details.

I think by making 4.2 version files named as 3.1 version in the project directory *might* fix this even if the next WU does not run in the same slot because isn't that were the appropriate slot files are copied from so they don't have to be downloaded everytime?

I'm also trying this now and will report back what happens. Seeing as we are getting a mix of 3.1 and 4.2 it may be quite a while.
____________
Thanks - Steve

Am I correct in that you need to do this every time you notice a cuda3.1 WU running?

Does anyone know how it notices ... is it smart enough to read the file's header or is it only looking at the timestamp. If it is only the time stamp I have code (at work) that uses the win32 api to set the stamp to whatever you tell it to be.
____________
Thanks - Steve

Does anyone know how it notices ... is it smart enough to read the file's header or is it only looking at the timestamp. If it is only the time stamp I have code (at work) that uses the win32 api to set the stamp to whatever you tell it to be.

Workaround V3.0 :)

For Windows XP:

1. Create a new folder for the files of the workaround.
2. Create a new text document in this folder called no.txt, and put a single n character in it.
3. Create a new text document called check.bat and put the following text in it:

SET GPUGRIDDIR=c:\Documents and Settings\All Users\Application Data\BOINC\projects\www.gpugrid.net\
SET SLOTDIR=c:\Documents and Settings\All Users\Application Data\BOINC\slots\
COMP "%GPUGRIDDIR%acemd.2562.cuda42" "%GPUGRIDDIR%acemd.win.2352" <no.txt
IF errorlevel 1 COPY "%GPUGRIDDIR%acemd.2562.cuda42" "%GPUGRIDDIR%acemd.win.2352" /y

FOR /L %%i IN (1,1,10) DO CALL slotcheck %%i


4. Create a new text document called slotcheck.bat and put the following text in it:

IF NOT EXIST "%SLOTDIR%%1\acemd.win.2352" GOTO slotnotcuda31
COMP "%GPUGRIDDIR%acemd.2562.cuda42" "%SLOTDIR%%1\acemd.win.2352" <no.txt
IF errorlevel 1 GOTO slotcopy
GOTO slotnotcuda31
:slotcopy
COPY "%GPUGRIDDIR%acemd.2562.cuda42" "%SLOTDIR%%1\acemd.win.2352" /y
COPY "%GPUGRIDDIR%cudart32_42_9.dll" "%SLOTDIR%%1\" /y
COPY "%GPUGRIDDIR%cufft32_42_9.dll" "%SLOTDIR%%1\" /y
:slotnotcuda31

5. Pause all CUDA3.1 tasks, and run check.bat. Restart all CUDA3.1 tasks.
6. Create a scheduled task to run the check.bat in every 5 minutes, or you can run it manually while no CUDA3.1 tasks running

For Windows 7 the first two lines of check.bat should be:
SET GPUGRIDDIR=c:\ProgramData\BOINC\projects\www.gpugrid.net\
SET SLOTDIR=c:\ProgramData\BOINC\slots\
In Windows 7 you need the highest access rights to run the batch file, so right click and choose "Run as administrator", or if you create a shortcut for it, check the "run as administrator" on the compatibility tab.
It checks slots 1-10, if you need more (or less) you can change it by changing the third number in the line beginnig with "FOR"

I tried your batch files. Seemed to run fine on the running task (cuda3.1) and made it run like a cuda4.2.

After that task ended, the next task was a cuda4.2 and errored out immediately.

Task Error

However, once the error task uploaded, I got another cuda4.2 task crunching fine. Who knows if it was just some weird issue.

Thank you for your report. This error could be by coincidence.
I have a different problem with the scheduling of this batch program:
When a new CUDA3.1 task is downloaded, it is receive an "error while downloading".
I couldn't catch it while it happened, I will keep an eye on it.
I think I can't cheat the BOINC manager, because it runs the client from the project's directory, not the slot's.
However, if a host do not receive a new CUDA3.1 task while a converted one is running, it could be fine.
So use my workaround with caution, and simply do not run it if it's causing problems. I will try to improve it. Until then I suggest you not to use it as a scheduled task.
Can anyone tell me, if there is a way to make the BOINC manager run the tasks from the slot's directory?

It sounds like all of you are receiving a combination of CUDA 3.1 and 4.2 tasks. I have the same issue. My real concern is that all of my cards are overclocked and CUDA 4.2 tasks may required a different hardware config that CUDA 3.1 tasks. It would be great to get only 4.2 work units going forward.
____________
Thx - Paul

Note: Please don't use driver version 295 or 296! Recommended versions are 266 - 285.

It would be quicker and simpler to create an app_info.xml file from the information already available in client_state, as I did for Running multiple tasks per GPU - count=0.5.

The downside is that you then have no chance of receiving new applications automatically - and it took until today for me to get round to finding, downloading, and implementing cuda42 on host 43404. Looks to have been well worth the effort.

I have a different problem with the scheduling of this batch program:
When a new CUDA3.1 task is downloaded, it is receive an "error while downloading".
I couldn't catch it while it happened, I will keep an eye on it.

I think I've had a cuda3.1 download after a cuda4.2, without an "error while downloading".

I'm not an expert, so does it makes sense that the cuda4.2 executable can run with the cuda3.1 dll's?

There is a Boinc flag to help with the earlier problem..

<dont_check_file_sizes>0|1</dont_check_file_sizes>

Here is my first converted workunit, which ran from the start to completion as a converted wu.
The second one is completed, but still uploading.

There is a Boinc flag to help with the earlier problem..

<dont_check_file_sizes>0|1</dont_check_file_sizes>

It's working!
Workaround V4.0:

1a. Put <dont_check_file_sizes>1</dont_check_file_sizes> in the options section in your cc_config.xml file
1b. If you don't have a cc_config.xml file, create a simple text file named cc_config.xml with the following content:

<cc_config>
<options>
<report_results_immediately>1</report_results_immediately>
<dont_check_file_sizes>1</dont_check_file_sizes>
</options>
</cc_config>

---the default location of the cc_config.xml file is
---on Windows XP: c:\Documents and Settings\All Users\Application Data\BOINC\projects\www.gpugrid.net\
---on Windows 7: c:\ProgramData\BOINC\projects\www.gpugrid.net\

2. Re-read configuration in BOINC manager

3. Pause all CUDA3.1 tasks

4a. On Windows XP run this batch program:

SET GPUGRIDDIR=c:\Documents and Settings\All Users\Application Data\BOINC\projects\www.gpugrid.net\
COPY "%GPUGRIDDIR%acemd.2562.cuda42" "%GPUGRIDDIR%acemd.win.2352" /y

4b. On Windows 7 run this batch program (right click) as an administrator:

SET GPUGRIDDIR=c:\ProgramData\BOINC\projects\www.gpugrid.net\
COPY "%GPUGRIDDIR%acemd.2562.cuda42" "%GPUGRIDDIR%acemd.win.2352" /y

5. Restart all CUDA3.1 tasks.

After that, every CUDA3.1 task will be running as CUDA4.2.

Trying to round out the conversation ...

RH: app_info is easier but you won't automatically get new versions.
My take = If I'm smart enough to even apply the app_info someone else creates I *should* be smart enough to keep track of the projects I am involved in to know when there are upgrades.

RZ: With adding the no check file size (thx MH) then the "swap file" only has to happen 1 time (well until you re-attach of the project).
My take = Using a bat file to make a copy of a file and rename it seems overly complex but mapping out what needed to happen has been extremely valuable!
Please also make sure that if you installed BOINC to a custom location the script needs to be modified accordingly.

Overall ... I'm sticking with the 1 time manual copy/ rename and have made an extra copy in a separate folder along with notes to reproduce if I need to re-attach.

Perhaps a new thread would be in order to investigate which WUs still process faster with 3.1 on 2XX series and how do we switch app versions on the fly. (I think this might just be a variation on RZ's script?)
____________
Thanks - Steve

It would be beneficial if there was some way to tell after the fact that a WU labeled 3.1 was processed using 4.2 for the user and the project in case troubleshooting was required for some problems with results or whatever. Hopefully no problems will arise.

Mark, thanks for pointing out the solution for the flaw of my workaround!

It would be beneficial if there was some way to tell after the fact that a WU labeled 3.1 was processed using 4.2 for the user and the project in case troubleshooting was required for some problems with results or whatever.

Hopefully no problems will arise.

Using a bat file to make a copy of a file and rename it seems overly complex but mapping out what needed to happen has been extremely valuable!

Looks like you need to have already run a 4.2 task in order to use the batch program?

Looks like you need to have already run a 4.2 task in order to use the batch program?

Looks like after a system reboot, the old cuda3.1 executable is downloaded again. So, it appears the batch file needs to be run after every reboot.


6/28/2012 10:42:30 PM | GPUGRID | Started download of acemd.win.2352

---the default location of the cc_config.xml file is
---on Windows XP: c:\Documents and Settings\All Users\Application Data\BOINC\projects\www.gpugrid.net\
---on Windows 7: c:\ProgramData\BOINC\projects\www.gpugrid.net\

You are right. Sorry, it's a copy-paste bug. Let's blame it on the heat.

The 3.1 DLLs are being pulled to the slot directory with the renamed 4.2 acmed file, is this correct ?

Yes. It's because the BOINC manager doesn't know that it's a CUDA 4.2 client.
If it's causing any trouble, you should simply copy the CUDA4.2 dll's into the Slot directory with my previous batch program from the GPUGrid project directory (make bacukups before doing so). But it won't cause problems, because the BOINC manager runs the client from the project's directory, not from the slot's (and doesn't copy it back from the slot directory).

It would be quicker and simpler to create an app_info.xml file from the information already available in client_state

I had my first two 4.2 tasks complete and validate. Now everything is failing with the message below. What happened?

Stderr output

<core_client_version>7.0.27</core_client_version>
<![CDATA[
<message>
- exit code 98 (0x62)
</message>
<stderr_txt>
# Using device 0
# There is 1 device supporting CUDA
# Device 0: "GeForce GTX 470"
# Clock rate: 1.40 GHz
# Total amount of global memory: 1341718528 bytes
# Number of multiprocessors: 14
# Number of cores: 112
MDIO: cannot open file "restart.coor"
ERROR: # Energies have become nan

called boinc_finish

</stderr_txt>
]]>

____________

From the posts I have kept up with that error is often caused by overclocking.

From the posts I have kept up with that error is often caused by overclocking.

I managed to get this running on a windows xp computer, with one video card, with no problem, by following the instructions. On a windows 7 computer with 2 video cards, it doesn't work for me. I followed the instructions, made sure the project and slot directories were correct,(mine were in a different location than listed on the postings, so I adjusted commands to those appropriate locations) and ran as administrator. Nothing!

Works for me on 2 XP machines and a W7 machine. Great post Retvari.

Thanks !

It's working!
I'm re-posting it to sum up some anwers, and the corrections in a single post:

You have to have CUDA4.2 capable NVidia drivers (v295.73 or later, v301.42 is recommended at the moment)
You have to have the CUDA4.2 application (acemd.2562.cuda42), and the CUDA4.2 runtime dll's (cudart32_42_9.dll, cufft32_42_9.dll) on your machine for this to work. I.e. your host should have downloaded at least one CUDA4.2 workunit before you can apply this workaround.
If you are not sure about this, you can check if your host already has the 3 required files in the project directory.
The default location of these files is:
on Windows XP: c:\Documents and Settings\All Users\Application Data\BOINC\projects\www.gpugrid.net\
on Windows 7: c:\ProgramData\BOINC\projects\www.gpugrid.net\
The easiest way to verify whether your own installation is using the default location is to look at the BOINC Manager message/event log: the working BOINC data directory is listed at around the fourth line after every BOINC restart. (you can get the correct path from that line)

Workaround V4.1:

1a. Put <dont_check_file_sizes>1</dont_check_file_sizes> in the options section in your cc_config.xml file
1b. If you don't have a cc_config.xml file, create a simple text file named cc_config.xml with the following content:

<cc_config>
<options>
<report_results_immediately>1</report_results_immediately>
<dont_check_file_sizes>1</dont_check_file_sizes>
</options>
</cc_config>

---the default location of the cc_config.xml file is
---on Windows XP: c:\Documents and Settings\All Users\Application Data\BOINC\
---on Windows 7: c:\ProgramData\BOINC\

2. Re-read configuration in BOINC manager

3. Pause all CUDA3.1 tasks

4. If you've installed the BOINC manager to it's default location, you can run one of the following batch programs according to your type of Windows.
Or you can manually copy the executable file of CUDA4.2 client over the CUDA3.1 client: acemd.2562.cuda42 -> acemd.win.2352
(the batch program can work on a non-default location too, if the path in the first line is corrected)

4a. On Windows XP run this batch program:

SET GPUGRIDDIR=c:\Documents and Settings\All Users\Application Data\BOINC\projects\www.gpugrid.net\
COPY "%GPUGRIDDIR%acemd.2562.cuda42" "%GPUGRIDDIR%acemd.win.2352" /y

4b. On Windows 7 run this batch program (right click) as an administrator:

SET GPUGRIDDIR=c:\ProgramData\BOINC\projects\www.gpugrid.net\
COPY "%GPUGRIDDIR%acemd.2562.cuda42" "%GPUGRIDDIR%acemd.win.2352" /y

5. Restart all CUDA3.1 tasks.

After that, every CUDA3.1 task will run as CUDA4.2, while the BOINC manager will still show they are CUDA3.1. It's because the BOINC manager doesn't know that it's a CUDA 4.2 client, so it won't copy the CUDA4.2 dlls into the slot directory, but it doesn't matter, because the BOINC manager runs the client from the project's directory, not from the slot's (and doesn't copy it back from the slot directory). If it's causing any trouble, you should simply copy the CUDA4.2 dll's into the Slot directory with my previous batch program from the GPUGrid project directory (make backups before doing so).

Thanks to every contributor!

Retvari, Thank you!
I received a long 31 wu two days ago. Est time to complete was over 15.5 hours. No way for me to complete within 24 hour bonus period so I aborted before it started. Yesterday I was assigned another long 31 wu with about 14.5 hours est to complete. It was going to sneak in under the 24 hour mark so I let it run. It started about 1:00 am today my time. When I checked this morning, the 31 wu had been running for over 8 hours and still had 11 hours est to complete. I was about to abort, thought I'd check the forums first, and found your workaround.
Wow! After implementing and restarting the task, the wu is humming along. Time to completion is reduced by 30 mins after just 14 mins of processing.

Of course, the wu still has to validate, but I am optimistic that it will do so and will qualify for 24 hr bonus.

I'm a noob at any kind of programming, and really far better with hardware than software, so I really appreciate the detail in your instructions.
I'll let you know if the task validates.
Thanks again!

Of course, the wu still has to validate, but I am optimistic that it will do so and will qualify for 24 hr bonus.

I'm a noob at any kind of programming, and really far better with hardware than software, so I really appreciate the detail in your instructions.

I'll let you know if the task validates.

The wu validated and I feel really good about my little programming venture, even though all I did was follow your instructions.

Thanks again!

Retvari,
I'm afraid I need a little more assistance. I received another cuda 31 long wu task. The workaround didn't automatically implement. After poking around, I discovered that it was because the slot directory had changed to slot 4, whereas last time I implemented the workaround in slot 1.

I redid the workaround for slot 4 and it is running fine now, but my questions are:
1. Why did it switch slots?
and,
2. Do I need to re-implement the workaround every time a cuda 31 task gets sent my way?

I was hoping there was a way to process 31's as 42's without my involvement, since I cannot sit in front of the screen all day to look for cuda 31's that download.

Do you have another rabbit to pull out of your hat?

(I run two 560 ti cards, 6 core AMD FX 6100 cpu, Win 7, 850W PSU, in case that info is helpful.)

Thank you!

This works by updating the file in the project directory. If you set up that short batch file:

4a. On Windows XP run this batch program:

SET GPUGRIDDIR=c:\Documents and Settings\All Users\Application Data\BOINC\projects\www.gpugrid.net\
COPY "%GPUGRIDDIR%acemd.2562.cuda42" "%GPUGRIDDIR%acemd.win.2352" /y

4b. On Windows 7 run this batch program (right click) as an administrator:

SET GPUGRIDDIR=c:\ProgramData\BOINC\projects\www.gpugrid.net\
COPY "%GPUGRIDDIR%acemd.2562.cuda42" "%GPUGRIDDIR%acemd.win.2352" /y


with the the following cc_config.xml file:

<cc_config>
<options>
<report_results_immediately>1</report_results_immediately>
<dont_check_file_sizes>1</dont_check_file_sizes>
</options>
</cc_config>

then it should work. I have to rerun the batch file after rebooting, but that's all the intervention I have to do. And you will potentially see a CUDA3.1 running, however it will be running using the CUDA4.2 files and be much faster.

One way you can verify is to confirm that in your GPUGrid project directory (potentially at C:\ProgramData\BOINC\projects\www.gpugrid.net on Win7), the files "acemd.win.2352" (CUDA3.1) and "acemd.2562.cuda42" (CUDA4.2) are the same size.

I did reboot recently and did not run the batch program. Ah ha moment! Now for the noob question. I don't know how to run a batch program so I manually copied the files and renamed as per the long version of the original workaround instructions. I have your exact cc_config file installed. I also checked the files you suggested and they are the same size. With the speed increase I'm seeing, I feel confident I did it correctly, but would much rather run a batch every time I reboot.

So, how do I run

SET GPUGRIDDIR=c:\ProgramData\BOINC\projects\www.gpugrid.net\
COPY "%GPUGRIDDIR%acemd.2562.cuda42" "%GPUGRIDDIR%acemd.win.2352" /y

as a batch program in Win 7?

It's ok to laugh at me - I laugh at myself, too. But, I do want to learn.

Thank you!

1. Why did it switch slots?

2. Do I need to re-implement the workaround every time a cuda 31 task gets sent my way?

I was hoping there was a way to process 31's as 42's without my involvement, since I cannot sit in front of the screen all day to look for cuda 31's that download.

Do you have another rabbit to pull out of your hat?

So, how do I run

as a batch program in Win 7?

However I do not recommend to run this batch program at every startup, because it can interfere with the BOINC manager, if a CUDA3.1 task is already running when this batch program starts.

Thank you both for the follow up! Good advice on what to do and when to do it.

I double checked the cc_config file and it is fine. Also, the error about file sizes does not show in my log. I use this rig almost entirely for GPUGrid, but do run a few files for other programs now and then. That prolly explains the slot change.

I created the .bat file per your instructions. Worked great! Only advice I would add for someone who is just as noob as me is to save the .bat file with the all files *.* extension, not the *.txt extension. I learned this lesson when creating the cc_config file for the first time.

Again, let me thank you for your detailed instructions. I'm slowly but steadily moving up the ranks in this project and wouldn't be without your assistance!

I noticed a couple things about this workaround reconversion. First, when I convert a cuda3.1 and reboot the computer afterwards, the unit often crashes. To avoid the crash you can, suspend the unit before rebooting, and then resume it after the computer has booted up. The second is, if you convert a cuda3.1 unit, and receive another one right after it, you don't have to run the conversion for the second unit for it to run as a cuda4.2. Of course, if you receive a cuda3.1, then one or more cuda4.2 in between, and then another cuda3.1, you have to convert both cuda3.1 units in order to for them to run as cuda4.2.

It seems to have worked for me as I don't appear to be getting any cuda 31 tasks.

MarkJ - It looks like you are runing GTX 670 (nice cards), the CUDA 3.1 app was never released for Kepler so yes, you always get the CUDA 4.2 app.

K1atOdessa - Taking a look at your tasks I see you processed a CUDA 3.1 on Aug1 - Aug 2 and another on Jul30 - Jul31
(http://www.gpugrid.net/results.php?hostid=114333)
____________
Thanks - Steve

All I did was a detach/reattach of the project. That will clean out the project folder and it will re-download apps. If your driver is a high enough version it should only give you a cuda 42 app and DLLs. It seems to have worked for me as I don't appear to be getting any cuda 31 tasks.

I have only long runs selected to be sent to my machine but I was sent a cuda31 wu today. My gtx 470 is compute capibility 2.0 and I have driver version 301.42. If this is supposed to happen still then disregard my post.

I have only long runs selected to be sent to my machine but I was sent a cuda31 wu today. My gtx 470 is compute capibility 2.0 and I have driver version 301.42. If this is supposed to happen still then disregard my post.