For a number of years SETI has only allowed 100 concurrent tasks for the CPU plus 100 per GPU.

---

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

Is there any workaround for this, since otherwise every downtime longer then a few hours and machine is becoming idle?

The workaround is anticipation of the loss of work due to the planned and unplanned outages. You can reschedule gpu work from the gpu cache and move it to the cpu cache in advance of an outage and then move it back by using any one of the rescheduling solutions. Rescheduling has had its own dedicated thread for a few years now. I suggest a read.
https://setiathome.berkeley.edu/forum_thread.php?id=79954&postid=1803817#1803817

---

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

A proud member of the OFA (Old Farts Association)

The most work we have ever been able to download for our work caches is 100 tasks per cpu + 100 tasks per gpu. So the days of work and additional days of work setting is meaningless on modern fast hosts. Maybe still applicable to phones and single board computers like the Raspberry Pi.

It would make sense that size of work cache is related to RAC... so maybe to keep 100+100 as default (minimum, appropriate for slow hosts) and to be increased to typical planned outage period based on RAC for each host. This way, everyone is happy, resources are optimally used, and also no "unnecessary" additional work is sent to hosts... Probably not so difficult to implement the logic...

---

Is there any workaround for this, since otherwise every downtime longer then a few hours and machine is becoming idle?

The workaround is anticipation of the loss of work due to the planned and unplanned outages. You can reschedule gpu work from the gpu cache and move it to the cpu cache in advance of an outage and then move it back by using any one of the rescheduling solutions. Rescheduling has had its own dedicated thread for a few years now. I suggest a read.
https://setiathome.berkeley.edu/forum_thread.php?id=79954&postid=1803817#1803817

I just use another project and set its resource share to zero. That way it only runs when seti is down or out of Wus and your computer doesn't sit idle.

It would make sense that size of work cache is related to RAC... so maybe to keep 100+100 as default (minimum, appropriate for slow hosts) and to be increased to typical planned outage period based on RAC for each host. This way, everyone is happy, resources are optimally used, and also no "unnecessary" additional work is sent to hosts... Probably not so difficult to implement the logic...

This topic has been raised innumerable times and the reality is that the current work cache size is not going to change. The project espouses that it has never guaranteed an endless supply of work and recommends backup projects when Seti has no work. The current work cache size was sufficient back when the project first started on the current hardware of the time and the use of the project was to make use of unused computer cycles when the Seti screensaver could run and crunch work in the background. It still hews to that original purpose, as you still have a Seti screensaver even though the performance capabilities of today's hardware is magnitudes greater than when the project started.

Also after 10 years of development, the BOINC code is very complicated and not so simple to fix or change as you suggest.

---

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

A proud member of the OFA (Old Farts Association)

You guys were right it was a VRAM issue. The GT 730 (2 GB VRAM) is up and running the CUDA60 app flawlessly. Thanks for your help.

Since you are running a GPU with 2 GB of VRAM you should go back to the default unroll setting. Just remove the -unroll 1 and it will go back to autotune and automatically run unroll 2 or whatever. The times will improve on that card using unroll 2.

Since you are running a GPU with 2 GB of VRAM you should go back to the default unroll setting. Just remove the -unroll 1 and it will go back to autotune and automatically run unroll 2 or whatever. The times will improve on that card using unroll 2.

Done. Thanks again.

Hi

Is there specific command line arguments that I should try for the RTX 2070 graphics card?

Thanks in advance,
BoincSpy

---

Without knowing what your hardware consists of because you have hidden your hosts, impossible to suggest anything.

---

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

A proud member of the OFA (Old Farts Association)

Sorry about that I thought I had the host visible. They are now visible...

Thank you in Advance.

---

Sorry about that I thought I had the host visible. They are now visible...

Thank you in Advance.

You could speed them up a bit by adding the -nobs parameter to the <cmdline></cmdline> entry location in either the app_info.xml or the app_config.xml.
Make sure you reduce your cpu thread usage as the -nobs parameter requires a full cpu core to support the gpu task.

---

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

A proud member of the OFA (Old Farts Association)

Thanks for the suggestion, I am now getting work-units being completed just shy of a minute..

---

I don't see any use of the -nobs parameter yet. Did you restart BOINC or re-read config files in the Manager?

---

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

A proud member of the OFA (Old Farts Association)

I just suspended boinc and restarted after I added nobs, I have no restarted boinc.. Here is portion of my app_info.xml

<app_info>
<app>
<name>setiathome_v8</name>
</app>
<file_info>
<name>setiathome_x41p_V0.98b1_x86_64-pc-linux-gnu_cuda101</name>
<executable/>
</file_info>
<app_version>
<app_name>setiathome_v8</app_name>
<platform>x86_64-pc-linux-gnu</platform>
<version_num>801</version_num>
<plan_class>cuda90</plan_class>
<cmdline>-nobs</cmdline>
<coproc>
<type>NVIDIA</type>
<count>1</count>
</coproc>
<avg_ncpus>0.1</avg_ncpus>
<max_ncpus>0.1</max_ncpus>
<file_ref>
<file_name>setiathome_x41p_V0.98b1_x86_64-pc-linux-gnu_cuda101</file_name>
<main_program/>
</file_ref>
</app_version>
...

---

Suspending BOINC does not read the app_info.xml. You have to completely restart it. If the parameter is placed in the app_config file, only a re-read of config files is necessary.

---

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

A proud member of the OFA (Old Farts Association)

Hi,
I am wondering if I should retrograde back to the previous version on both of my HEDC boxes?

I am still seeing a lot of inconclusives on a daily basis. And while some of them are "Darwin" disagreements, at least some are not.

Could someone take a look and offer and opinion.

I know some of my problems were pushing my AMD cpu harder than it appears to be able to work. But a lot are just plain inconclusives.

Thank you.

Tom

---

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

I don't see anything out of the ordinary. You can discount all the overflows too.

---

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

A proud member of the OFA (Old Farts Association)

I don't see anything out of the ordinary. You can discount all the overflows too.

Ok, Thank you.

I just hate slowing things down because of a simple fixable problem.

Tom

---

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

Updated to 0.98b1 CUDA90

In stderr:
@
SETI@home using CUDA accelerated device GeForce GTX 1050 Ti
Unroll autotune 1. Overriding Pulse find periods per launch. Parameter -pfp set to 1
@

Should I change params or it's OK for Ti1050 to go with such default settings?

. . I thought that unroll =1 was the default for 0.98b1 because it has the reduced external access process that keeps everything in memory on the GPU for pulse find so the unroll doesn't matter.

Stephen

? ?