I read some of the readme files, I guess I missed the one with a few useful lines in it.

To help others find it.
The file that covers -nobs is in the projects/setiathome.berkelyey.edu/docs/README_x41p_V0.98.txt

There are 2 with similar names and they start out the same Read the second one.

For anyone else out there...
There is a README in the All-In-One that covers most of what is in this thread. It Helps if you Read the Manual.
As for assigning One CPU per GPU, that Will Not Work on some machines, the Default setting Will Work.
All you are doing by assigning a full CPU to a GPU is telling BOINC to Not Start a task unless there is One full CPU available. That BOINC setting has absolutely No Control over how much CPU the App uses. The App nobs setting controls how much CPU the App uses, and nobs doesn't require a Full CPU to start a task.

---

Might as well post the ReadMe for those that either can't, or won't even bother, to find it. It does contain a couple items not in the thread.
But first, I went through the trouble of once again Testing what changing the setting to <max_ncpus>1</max_ncpus> actually does, because, obviously some will never bother to Test it.
The first times were using the Default, <max_ncpus>0.1</max_ncpus>;

<name>blc32_2bit_guppi_58643_64747_HIP85822_0066.15379.0.23.46.136.vlar_1</name>
<final_cpu_time>34.643260</final_cpu_time>
<final_elapsed_time>348.145598</final_elapsed_time>

The Next was using <max_ncpus>1</max_ncpus>;

<name>blc32_2bit_guppi_58643_64747_HIP85822_0066.15379.0.23.46.136.vlar_1</name>
<final_cpu_time>34.815690</final_cpu_time>
<final_elapsed_time>348.145931</final_elapsed_time>

As you can see, there isn't any effective difference, mainly because the setting <max_ncpus></max_ncpus> only deals with BOINC Scheduling and doesn't have any affect on the Science App. My advice is to leave it set to Default which is much closer to the number the Original nVidia CUDA Team decided on nearly 12 Years ago.

README_x41p_V0.98.txt

This App will only work on GPUs that are Compute Capability 5.0 or higher, in Ubuntu 14.04.1 or higher.
See list of supported GPUs here, https://en.Wikipedia.org/wiki/CUDA#GPUs_supported

To get started, open the BOINC folder and double-click on boincmgr, then add SETI@home to BOINC.

For best use;
1) You should reserve CPU usage for the GPU App by changing the "Use at most ___ % of the CPUs" to at least 99%
in the BOINC - Computing preferences. For multiple GPUs you need to reserve more CPU usage. The App will run poorly
without Free CPU time available.

2) Use a Newer CUDA 9.0+ driver, CUDA90 needs at least 384.130, CUDA101 at least 418.x, the Repository driver 384.130 should work for the CUDA90 App.

3) Run One Task per GPU, running more will not improve output and will use twice as much vRam.

4) With this version -unroll autotune and Blocking Sync is set by default. Override Autotune with the cmdline -unroll N, Blocking Sync override is -nobs

5) If you wish to use 100% CPU per task, add the command -nobs to the CUDA section of the app_info.xml,
<plan_class>cuda90</plan_class>
<cmdline>-nobs</cmdline>
<coproc>
There isn't any requirement to use a Full CPU per task, but, it may be a few seconds faster.
(In my experience, the more complex the system, the more effect nobs will have.)

6) The App may give Incorrect results on a restarted task. One way to avoid restarted tasks is to set the checkpoint higher than the longest task's estimated run-time, and also avoid suspending/resuming a task.

7) If you have an AMD CPU move the AMD CPU App in the folder 'For AMD CPUs' to the root level, change the App names in the CPU section of the app_info.xml (<name> & <file_name>), and see if that works better.
If you have a CUDA 10.1 driver you can use the CUDA101 App, change the app_info.xml to name the CUDA 10.1 App in the Two locations, <name> & <file_name>
( Note there isn't anything there about changing anything other than the App Name.)

8) The CPU Progress bar may stall with High AR Work Units, the task will finish normally, it's just the Progress Bar that's stalled.

Might as well post the ReadMe for those that either can't, or won't even bother, to find it. It does contain a couple items not in the thread.
But first, I went through the trouble of once again Testing what changing the setting to <max_ncpus>1</max_ncpus> actually does, because, obviously some will never bother to Test it.
The first times were using the Default, <max_ncpus>0.1</max_ncpus>;

<name>blc32_2bit_guppi_58643_64747_HIP85822_0066.15379.0.23.46.136.vlar_1</name>
<final_cpu_time>34.643260</final_cpu_time>
<final_elapsed_time>348.145598</final_elapsed_time>

The Next was using <max_ncpus>1</max_ncpus>;

<name>blc32_2bit_guppi_58643_64747_HIP85822_0066.15379.0.23.46.136.vlar_1</name>
<final_cpu_time>34.815690</final_cpu_time>
<final_elapsed_time>348.145931</final_elapsed_time>

As you can see, there isn't any effective difference, mainly because the setting <max_ncpus></max_ncpus> only deals with BOINC Scheduling and doesn't have any affect on the Science App. My advice is to leave it set to Default which is much closer to the number the Original nVidia CUDA Team decided on nearly 12 Years ago.

README_x41p_V0.98.txt

This App will only work on GPUs that are Compute Capability 5.0 or higher, in Ubuntu 14.04.1 or higher.
See list of supported GPUs here, https://en.Wikipedia.org/wiki/CUDA#GPUs_supported

To get started, open the BOINC folder and double-click on boincmgr, then add SETI@home to BOINC.

For best use;
1) You should reserve CPU usage for the GPU App by changing the "Use at most ___ % of the CPUs" to at least 99%
in the BOINC - Computing preferences. For multiple GPUs you need to reserve more CPU usage. The App will run poorly
without Free CPU time available.

2) Use a Newer CUDA 9.0+ driver, CUDA90 needs at least 384.130, CUDA101 at least 418.x, the Repository driver 384.130 should work for the CUDA90 App.

3) Run One Task per GPU, running more will not improve output and will use twice as much vRam.

4) With this version -unroll autotune and Blocking Sync is set by default. Override Autotune with the cmdline -unroll N, Blocking Sync override is -nobs

5) If you wish to use 100% CPU per task, add the command -nobs to the CUDA section of the app_info.xml,
<plan_class>cuda90</plan_class>
<cmdline>-nobs</cmdline>
<coproc>
There isn't any requirement to use a Full CPU per task, but, it may be a few seconds faster.
(In my experience, the more complex the system, the more effect nobs will have.)

6) The App may give Incorrect results on a restarted task. One way to avoid restarted tasks is to set the checkpoint higher than the longest task's estimated run-time, and also avoid suspending/resuming a task.

7) If you have an AMD CPU move the AMD CPU App in the folder 'For AMD CPUs' to the root level, change the App names in the CPU section of the app_info.xml (<name> & <file_name>), and see if that works better.
If you have a CUDA 10.1 driver you can use the CUDA101 App, change the app_info.xml to name the CUDA 10.1 App in the Two locations, <name> & <file_name>
( Note there isn't anything there about changing anything other than the App Name.)

8) The CPU Progress bar may stall with High AR Work Units, the task will finish normally, it's just the Progress Bar that's stalled.

TBar, thanks very much from a relative newbie to the arcanities of Linux and Seti on Linux. I have just completed one switchover from Win to Linux (Ubuntu) using your package totally out of the box. It was relatively painless and seems to be working very effectively. I can see why you call it the "All-in-one". Just install and reap the enhanced credits!

---

Arnie
Alberta, Canada

When I run the default for the cpu to gpu ratio (seems to be 0.10 to 1) with -nobs on the commandline two things happen.

The task manager pegs 100%. And I start running 14 cpu threads as well as 6 gpu threads. This system has an Amd 2700 (8c/16t).

My cpu % is set to 90.
The individual threads as reported by the task manager are sometimes running as low as 2% and upto 6%. 6% is "normal" when there is 1 cpu per 1 gpu.

The only way I can get the task manager to stop pegging 100% is to back off the cpu% down to around 65%.

That puts me back in the same cpu and gpu threads as running a 1.0 to 1.0 cpu to gpu ratio.

Am I missing something?

Tom

---

A proud member of the OFA (Old Farts Association).

When I run the default for the cpu to gpu ratio (seems to be 0.10 to 1) with -nobs on the commandline two things happen.

The task manager pegs 100%. And I start running 14 cpu threads as well as 6 gpu threads. This system has an Amd 2700 (8c/16t).

My cpu % is set to 90.
The individual threads as reported by the task manager are sometimes running as low as 2% and upto 6%. 6% is "normal" when there is 1 cpu per 1 gpu.

The only way I can get the task manager to stop pegging 100% is to back off the cpu% down to around 65%.

That puts me back in the same cpu and gpu threads as running a 1.0 to 1.0 cpu to gpu ratio.

Am I missing something?

Tom

You know my answer to this. Set CPU to 100%. Add a <project_max_concurrent>15</project_max_concurrent> to your app_config and see it that improves your throughput. And let's not get into the same old arguments. Just test it and see how it goes.

---

yes, as has been said in the past, the ncpus value tells BOINC how much CPU you are using. and BOINC trusts that number. So if you lie to BOINC about how much CPU you are using, it will do counter intuitive things like this. There are only very very niche reasons to do this, that seem to affect only one user's setup. everyone else prefers to use the 1:1 setup so that BOINC properly knows how much CPU you're using and can manage CPU percentage properly, accurately, and intuitively when you change that value in the compute settings. for example, setting the CPU% value to 80% actually results in ~80% usage rather than some other value.

if you are trying to run CPU work and GPU work together while leaving ncpus at 0.1 with -nobs added, you have to use some pretty kludgey settings to make it work how you actually want. as you have discovered.

or you can do what nearly everyone else does, set ncpus to 1.0 so BOINC knows you are using a full core and properly accounts for it when you tell it how you want it to act in the compute settings.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

When I run the default for the cpu to gpu ratio (seems to be 0.10 to 1) with -nobs on the commandline two things happen.

The task manager pegs 100%. And I start running 14 cpu threads as well as 6 gpu threads. This system has an Amd 2700 (8c/16t).

My cpu % is set to 90.
The individual threads as reported by the task manager are sometimes running as low as 2% and upto 6%. 6% is "normal" when there is 1 cpu per 1 gpu.

The only way I can get the task manager to stop pegging 100% is to back off the cpu% down to around 65%.

That puts me back in the same cpu and gpu threads as running a 1.0 to 1.0 cpu to gpu ratio.

Am I missing something?

Tom

The way to reduce the Task Manager to below 100% is to lower the Use at most __ % of the CPUs until you get the desired numbers. It's the way it's been done Forever.
I don't see why yours should be any different. If you still think changing the ncpus changes anything to do with CPU times, then RUN THE TEST. You can't argue about the TEST.
Changing the ncpus to one will change one thing for sure, it will keep any machine from running more GPU tasks than it has CPU cores. Your 4 core machine will run Only 4 GPU tasks instead of 12, your 8 core machine will only run 8 GPU tasks instead of 20. With the CUDA App running before BLC it was common to run 4 GPUs with 3 tasks each totaling 12 GPU tasks on your 8 Core CPU. You can't do that with ncpus set to One.

When I run the default for the cpu to gpu ratio (seems to be 0.10 to 1) with -nobs on the commandline two things happen.

The task manager pegs 100%. And I start running 14 cpu threads as well as 6 gpu threads. This system has an Amd 2700 (8c/16t).

My cpu % is set to 90.
The individual threads as reported by the task manager are sometimes running as low as 2% and upto 6%. 6% is "normal" when there is 1 cpu per 1 gpu.

The only way I can get the task manager to stop pegging 100% is to back off the cpu% down to around 65%.

That puts me back in the same cpu and gpu threads as running a 1.0 to 1.0 cpu to gpu ratio.

Am I missing something?

Tom

You know my answer to this. Set CPU to 100%. Add a <project_max_concurrent>15</project_max_concurrent> to your app_config and see it that improves your throughput. And let's not get into the same old arguments. Just test it and see how it goes.

I started a test about the same time I posted the question earlier today with cpu cores at 90% and the defaults project_max for gpu spoofing. And right now the RAC has stopped falling (I ended up with 6 gpus instead of the 9 I had for while because of the new Aus C7H mb).
So either I am experiencing some LAG issues from previous changes or it actually is processing faster. I dunno. Will have to run it a while....

Tom

---

A proud member of the OFA (Old Farts Association).

You know my answer to this. Set CPU to 100%. Add a <project_max_concurrent>15</project_max_concurrent> to your app_config and see it that improves your throughput. And let's not get into the same old arguments. Just test it and see how it goes.

I started a test about the same time I posted the question earlier today with cpu cores at 90% and the defaults project_max for gpu spoofing. And right now the RAC has stopped falling (I ended up with 6 gpus instead of the 9 I had for while because of the new Aus C7H mb).
So either I am experiencing some LAG issues from previous changes or it actually is processing faster. I dunno. Will have to run it a while....

Tom

Well, the RAC is still climbing. And once I have my new cpu cooler installed I can OC the cpu.

I suspect what is going on is
1) The gpus are still running "at speed" because of the -nobs
2) I have nearly doubled the number of cpu threads that are crunching cpu tasks. And while they have slowed down, they haven't started taking twice as long.
So #2 is producing a net gain.

Tom

---

A proud member of the OFA (Old Farts Association).

I think it is about as good as it can get without adding another GPU. I noticed a decrease in speed, but it was because it somehow reverted back to an old copy of the config file. I'm not sure if it was something I did on accident (I really don't think so). Anyways, got that squared away. GPU is still a bit warm but I have the peaks down to right about 70C. I might cut a hole in the case to allow the hot air from the GPU heatsink to exit directly. My gpu tasks are averaging about 37 seconds after fixing the config issues this evening.

Learned a fair amount, most importantly - read ALL the files carefully :)

Thanks
Eric

---

Thanks very much for the super easy package and the good tips!

Yes - I;m also happy to have so nice tutorial.
Just one question - after steps mentioned earlier, will BM start together with Ubuntu? or I have to put it into startup programs?

---

As with many thing Linux - that depends.
For two out of my three Linux boxes it went straight into the start-up list, but on the third it didn't......

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Thx - I will have to check it then, but it's risky :) It's remote host + not always boots up + person who have access for it is out for few days.

---

You know my answer to this. Set CPU to 100%. Add a <project_max_concurrent>15</project_max_concurrent> to your app_config and see it that improves your throughput. And let's not get into the same old arguments. Just test it and see how it goes.

I started a test about the same time I posted the question earlier today with cpu cores at 90% and the defaults project_max for gpu spoofing. And right now the RAC has stopped falling (I ended up with 6 gpus instead of the 9 I had for while because of the new Aus C7H mb).
So either I am experiencing some LAG issues from previous changes or it actually is processing faster. I dunno. Will have to run it a while....

Tom

Well, the RAC is still climbing. And once I have my new cpu cooler installed I can OC the cpu.

I suspect what is going on is
1) The gpus are still running "at speed" because of the -nobs
2) I have nearly doubled the number of cpu threads that are crunching cpu tasks. And while they have slowed down, they haven't started taking twice as long.
So #2 is producing a net gain.

Tom

I got the oversized cooler installed a Friday. With major assistance from Keith it ran over night without crashing at 4Ghz. And seems to be stabilizing at about 375,316.07 for the RAC.
I need to go look at the latest cpu tasks. When I looked at them yesterday, the wallclock time and cpu time will not tracking real closely.
It maybe that there is a compromise like that will increase production while while letting the cpu tasks times come closer together.

I will try going from 90% cpu cores to 100% to see what happens today. Later I will try 90% and 1/2 cpu to 1 gpu (its 0.10 cpu to 1 gpu now) and see what happens to the RAC.

Tom

---

A proud member of the OFA (Old Farts Association).

You know my answer to this. Set CPU to 100%. Add a <project_max_concurrent>15</project_max_concurrent> to your app_config and see it that improves your throughput. And let's not get into the same old arguments. Just test it and see how it goes.

I started a test about the same time I posted the question earlier today with cpu cores at 90% and the defaults project_max for gpu spoofing. And right now the RAC has stopped falling (I ended up with 6 gpus instead of the 9 I had for while because of the new Aus C7H mb).
So either I am experiencing some LAG issues from previous changes or it actually is processing faster. I dunno. Will have to run it a while....

Tom

Well, the RAC is still climbing. And once I have my new cpu cooler installed I can OC the cpu.

I suspect what is going on is
1) The gpus are still running "at speed" because of the -nobs
2) I have nearly doubled the number of cpu threads that are crunching cpu tasks. And while they have slowed down, they haven't started taking twice as long.
So #2 is producing a net gain.

Tom

I got the oversized cooler installed a Friday. With major assistance from Keith it ran over night without crashing at 4Ghz. And seems to be stabilizing at about 375,316.07 for the RAC.
I need to go look at the latest cpu tasks. When I looked at them yesterday, the wallclock time and cpu time will not tracking real closely.
It maybe that there is a compromise like that will increase production while while letting the cpu tasks times come closer together.

I will try going from 90% cpu cores to 100% to see what happens today. Later I will try 90% and 1/2 cpu to 1 gpu (its 0.10 cpu to 1 gpu now) and see what happens to the RAC.

Tom

So far the RAC has been flat. I am being nagged to go back to 1:1 cpu to gpu on another thread. Guess I will try that tonight and see what happens.

Tom

---

A proud member of the OFA (Old Farts Association).

It appears you Never did lower your CPU use. Your CPU Times show Massive Over-commitment, if you weren't running nobs your GPU times would be Dismal, to say the least. If you are running GPU(s) and your CPUs are at 100% in the Task Manager, then the GPUs are being CPU staved. Running nobs helps, but, you should lower your CPU use below 100% in the Task Manager. Keep lowering CPU use until the Task Manager shows around 80-90%.

So far the RAC has been flat.

And as I have pointed out many times in the past, RAC is not a good indicator of performance over the long term; while over the short term it's worse than useless.
The number of WUs processed per hour, of a given type, is the only meaningful & accurate indicator of performance.

---

Grant
Darwin NT

Running nobs helps, but, you should lower your CPU use below 100% in the Task Manager. Keep lowering CPU use until the Task Manager shows around 80-90%.

Or just reserve a CPU core to support each GPU WU being processed.

In app_confi.xml

<app_config>
 <app>
  <name>setiathome_v8</name>
  <gpu_versions>
  <gpu_usage>1.0</gpu_usage>
  <cpu_usage>1.0</cpu_usage>
  </gpu_versions>
 </app>
 </app_config>

It's that simple.

No more overcommitted CPU.

---

Grant
Darwin NT

Let's see.... A GTX 750 Ti uses about 0.1 % of a CPU core running the CUDA App. That means on a 4 core CPU I can run Three 750 Ti and 2 or 3 CPU tasks and still be below 100% CPU.
Using Your method, running Three GPUs would tie up 75% of the CPU, leaving One core to run a CPU App. That doesn't sound so good to me. It's also just as easy to lower the CPU use in BOINC Manager, in fact, most would say it's easier to set that setting in BOINC than to make and place a File. Not to mention if you ever wanted to run say, 5 GPUs on that 4 core CPU, your method wouldn't work.