I just tried it with Ubuntu 16.04 and driver 375.66 by making the links to the CUDA 6.0 Libraries and renaming the links libcudart.so.6.5 & libcufft.so.6.5 and it works here. The files must end in 6.5, Not 6.5.0. I left the app_info.xml the way it was naming libcudart.so.6.0 & libcufft.so.6.0. The only change was making and renaming the links. In the setiathome.berkeley.edu folder you would end up with 4 CUDA files, 1 pair ending in 6.0 and the other pair ending in 6.5. If that doesn't work for you, you're going to have to download and install the CUDA Toolkit 6.5 and use the Libraries from usr/local/cuda-6.5/lib64. Copy the libcudart.so.6.5.19 & libcufft.so.6.5.19 files to setiathome.berkeley.edu and rename them to libcudart.so.6.5 & libcufft.so.6.5. You will also need to change the entries in the app_info.xml to name the 6.5 libraries instead of the 6.0 libraries, just change the 0 to 5. I was hoping to keep people from having to download the CUDA Toolkit, but apparently that's not working.
The CUDA Toolkit 6.5 is here, https://developer.nvidia.com/cuda-downloads-geforce-gtx9xx
If your OS isn't listed choose the Ubuntu version, you might have to choose the --override install if your compiler isn't supported. You don't need the compiler, all you need is the 2 CUDA Libraries. Kinda a pain for just 2 files, but if it's all that will work you don't have much choice.
Good Luck.

OK TBar, I have gotten it running.

I never used Linux before, I'm a complete rookie and I am making rookie mistakes.
I appreciate everybodys help and patience.

Now, it turns out I was renaming the file wrong (another rookie mistake). I went back and renamed the link from 6.5.0 to 6.5, it did not work, but it might have if I deleted the old one and made a new link with it renamed correctly. I went instead to my storage disk, where I had fresh copies of the 6.0 files (named wrong of course), changed there names by deleting the .0, and copied them to the SETI dir. Changed app_info to the new 6.5. Rebooted

When I selected the files to rename it did not highlight the .0, it treated it like an extension. I didn't know any better so I just added the .5 behind the 6 and saved. Turns out that was wrong, I am glad you pointed that out in you post.

Now that it is running I hope that fixes the invalid problem.

Jump in the deep end, sink or swim.

---

Bruce

It looks to be working OK now. You really shouldn't need to make any links, we've run Apps before using different Libraries by just naming the Libraries in the app_info.xml. The CUDA75 Special App ran fine with the CUDA65 Libraries for over a year by just naming the Libs in the app_info.xml. For some reason that App is demanding Libs different from what is listed. I wonder if it would be better just to list the CUDA65 Libs in the app_info.xml and just tell people to rename the Downloaded 6.0 Libraries to 6.5. Either way would be easier than having to download and install the CUDA Toolkit for just those 2 Libraries. Too bad the Libs are too big to post at Crunchers Anonymous. It would be nice if you could download them from nVidia or someplace else without having to install the Toolkit, fortunately the CUDA60 Libs are on the SETI Server, the CUDA65 Libs aren't on the Server. I'll have to think about it.

That's what I thought, I'll have to give it awhile and see what happens.

Does this app require the Cuda60 libraries or will it work on newer ones?
If the app would work with the Cuda65 libraries maybe they could also list the Cuda65's on the SETI Server, or replace the Cuda60's with the 65's.
I see that my Package Manager lists the Cuda75 libraries, would they work?

I don't have the slightest idea how you have things setup, so maybe something to think about.

Thanks for the help.

---

Bruce

The Libraries should be the same CUDA version as the App, usually One version older Libraries are fine, two versions older would be stretching it. The Libraries should Not be newer than the App. The only change I would recommend would be to use the CUDA 6.5 Libraries with the CUDA 6.5 App, but that would mean downloading and installing the previously mentioned ToolKit. The only reason the CUDA 6.0 Libraries are on the SETI server is because there is an existing CUDA 6.0 Stock Linux App. Otherwise there wouldn't be any Linux CUDA Libraries on the server. You might see faster times using the 6.5 Libraries, or you might not, I don't think they would be worse though. It seems to be doing fine the way it is, it's not much slower than with the 8.0 App, and it shouldn't give any Invalids.

Oh, I forgot to mention another one of the features BOINC 7.2.47 has over the older 7.2.42;

1) Shows the CUDA driver version
2) Finds the OpenCL Library when using the Repository driver
3) Works in Newer versions of Ubuntu and 'may' work in other newer versions of Linux
4) Comes in an All In One package with the CUDA 8.0 Special App and supporting Apps Pre-Installed
5) Allows caching of up to 3k tasks

Nice features, and it also doesn't cause the Tasks Page to Jump to the Bottom of the Page during Scheduler Updates.

I've switched from 7.8.0 to 7.2.47 but no way to find how to get the 3k tasks caching....hiding feature ?

---

I've switched from 7.8.0 to 7.2.47 but no way to find how to get the 3k tasks caching....hiding feature ?

Curious myself. Where is that parameter hiding?

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

3k tasks seems just what I need, I will switch BOINC if it works.

...Allows...

Allowing something is different than actually doing something.
If you haven't figured it out, I would suggest determining what the GUPPI Rescheduler is doing that results in the increased cache.
You don't need a script to do what the Rescheduler does, all you need is a text editor that can copy and paste 3 lines into the Find field, such as gedit.

...Allows...

Allowing something is different than actually doing something.
If you haven't figured it out, I would suggest determining what the GUPPI Rescheduler is doing that results in the increased cache.
You don't need a script to do what the Rescheduler does, all you need is a text editor that can copy and paste 3 lines into the Find field, such as gedit.

. . That is waaayyy too cryptic for me :(

Stephen

:(

...Allows...

Allowing something is different than actually doing something.
If you haven't figured it out, I would suggest determining what the GUPPI Rescheduler is doing that results in the increased cache.
You don't need a script to do what the Rescheduler does, all you need is a text editor that can copy and paste 3 lines into the Find field, such as gedit.

Try to decode the signal...;)

"boinc v7.2.47 CAN handle 3000 tasks...but will not do the job.
You can use an editor to modify the client_state.xml file...all you need is to change <version_num>, <plan_class> and <platform> tags."

I agree it can be done manually but a script is easier to launch and can do the job when you are away from the keyboard.

---

Yes, it will allow you to do the deed, but not do it for you. In concept it would only be used once a week on machines that would otherwise run out of work a few hours into a 12 hour outrage. It really isn't useful for any other scenario, except perhaps Wow bunkering.

Somebody is going to have to lead us through the maze. I tried opening the Rescheduler with Gedit and it complained of invalid characters and any editing would destroy the file. I have no clue how changing any entry in client_state.xml produces the 3K result on board setting. Don't know enough about what and why client_state has values in it other than a record of what tasks are on board and basic account housekeeping. I have not needed to study whatever documents are around that define client_state so far.

So is the 3K reference just a teaser to entice people to try the 7.2.47 BOINC platform and in reality that "feature" is unavailable unless one is a competent programmer already familiar with the BOINC code?

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

HaHa....this is a joke right?
Here, read this recent post again...carefully;

https://setiathome.berkeley.edu/forum_thread.php?id=80636&postid=1885372#1885372
....It seems you have a number of GPU tasks, there are just Ghosts. That happens when you use a different Version number or Plan Class in your app_info.xml when you have Existing tasks assigned to one particular set of numbers. If you have Existing tasks, you must keep the numbers in your app_info.xml the same as the ones in your client_state.xml.

I think even Stephen has figured out how to run Arecibo vlars on his GPU. Try this, sort the tasks by application and suspend most of your GPU tasks. Stop BOINC, open client_state.xml with gedit and search for sus. Look at the two lines directly above suspended and compare them to your app_info.xml, then look at what line is used to assign tasks to your CPU...it's usually just one line. All you have to do is replace all those >version_num<, >plan_class<, and >suspended< lines with the single >version_num< line for you CPU. When you start BOINC again all those moved tasks will be replaced by New GPU tasks. Do that a number of times and you will have Hundreds of GPU tasks assigned to your CPU. The final step would be to reassign all those moved GPU tasks back to your GPU, again, suspend the now CPU tasks and just find and replace the >version_num< & >suspended< lines with the two lines for your GPU. That's basically what the Rescheduler does, in this case the >suspended< line identifies the specific lines to be replaced. Once the lines have been entered into the Find and Replace fields of gedit they are saved so the next time you don't even have to copy and paste, just select the correct sequence of lines by hitting the triangles in Find & Replace. Use that method and you'll stop trashing your CPU's APR. I would suggest practicing while OFFLINE with a duplicate BOINC folder. Once you can edit the file without startup problems you might be ready to go live, and yes, it's much easier with the BOINC folder in your Home folder.

"...a teaser to entice people to try the 7.2.47 BOINC platform" Am I missing something? Should I be taking Donations to use the App? HaHaHa
It's what I use, I really don't care what anyone else uses.

I would be amazed if Stephen could figure out what you just described. I certainly couldn't. And I have always tried to NOT make 'ghosts' as they are downright painful and tedious to recover 20 at a time. You were certainly cryptic with your reference to the Rescheduler and I merrily followed the path you inferred about needing to edit it with gedit. I will have to read your process at least a couple more times to understand what is happening.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I understood it but have no desire to ever try it, lol.. I'm perfectly happen with the way things run.

---

This is pretty much spot on;

"boinc v7.2.47 CAN handle 3000 tasks...but will not do the job.
You can use an editor to modify the client_state.xml file...all you need is to change <version_num>, <plan_class> and <platform> tags."

The only difference is you don't need the <platform> tag as it's always the same with 64 bit Linux. What you need is the <suspended> tag to identify which task to reschedule. It does exactly what the rescheduler does, it assigns the GPU tasks to your CPU and visa versa. It shouldn't be that difficult for someone already familiar with the rescheduler.

This is pretty much spot on;

"boinc v7.2.47 CAN handle 3000 tasks...but will not do the job.
You can use an editor to modify the client_state.xml file...all you need is to change <version_num>, <plan_class> and <platform> tags."

The only difference is you don't need the <platform> tag as it's always the same with 64 bit Linux. What you need is the <suspended> tag to identify which task to reschedule. It does exactly what the rescheduler does, it assigns the GPU tasks to your CPU and visa versa. It shouldn't be that difficult for someone already familiar with the rescheduler.

Petri send me another procedure which seems to me more easier .... I wrote a small script to do the job. If anyone is interested in ....it's a perl script.
It works fine for me but need to be tested as your app_info may differ than mine (it produce ghost for some)
You need to stop boinc, launch the script, restart and wait for new CPU tasks to download (which may take a while if you exceeded the daily limit :( ...it works well
with slow graphics card (as GTX 1050 Ti) but require to restart the procedure as downloading only 100 new tasks is not enough for fast graphic card to be able
to compute for the next 12 hours....

---

...and wait for new CPU tasks to download (which may take a while if you exceeded the daily limit :( ...it works well with slow graphics card (as GTX 1050 Ti) but require to restart the procedure as downloading only 100 new tasks is not enough for fast graphic card to be able to compute for the next 12 hours....

Hmmm, this sounds similar to what the Rescheduler does, download mostly CPU tasks, run them on the GPU, which ends up destroying your CPU's APR to the point a CPU task will error out when run on a CPU. Anyway you can change it to download GPU tasks so it ends up running GPU tasks on the GPU? That's the way my method works, and since users normally have 3 or 4 GPUs you end up downloading Hundreds of tasks at a time. I usually download close to 300 GPU tasks at a time on my 3 GPU machine, which means it doesn't take long to fill a cache. It takes a bit longer on the two GPU machine, but, you don't have to download as many tasks ;-)

It does exactly what the rescheduler does, it assigns the GPU tasks to your CPU and visa versa. It shouldn't be that difficult for someone already familiar with the rescheduler.

We normal, non-code writing setizens may use the Rescheduler but have not a clue how it works. It's magic as far as I can tell.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)