We have been monitoring the situation, and it seems like the community has found fixes to some of the problems you are experiencing.

Jake said that the problem appeared to be some obscure BOINC setting somewhere, and had asked BOINC forums about it. It looks like this issue disappears in the new beta of a BOINC client, so they must have patched whatever was causing problems. When that is released, hopefully the problem will be resolved.

- Tom

Setup a 2nd gpu project with a zero resource share so when MW runs out it will get tasks and your gpu won't be idle while waiting for MW to refill the cache. PrimeGrid and Collatz are two projects that almost always have tasks, at PrimeGrid you can pick wu's that run very quickly like the MW wu's do and at Collatz if you do use the optimization codes the wu's will run much faster as well.

This is just a workaround, not a solution.. developers must fix it

This is for sure a server-side misconfiguration, in 15years of boinc it never happened with any other project

when you ron out of WU the first deferred communication is always more or less 1.40minutes.. in this first stage it uploads the latest results (and don't downloads anything)

then begin the second deferred communication of more or less 12minutes (can't remember).. the gpu is idling and then since no results to report, the downloads of 300wu begin

this loop is always the same on all hosts.. next time i'll run out of WU i will post the exact times..

0130 Thursday (Central EU time) the reinstallation of studio driver manually seems to have fixed this issue.
task is running ok.

200 computed tasks in less 10 minutes? It is not possible even for fastest machines. Very best computers with few modern powerful GPUs working in parallel dedicated to the single project of MW can do 200 tasks "only" in ~20-40 min.

Beg to differ. If I have a host with 8 RTX 2080 TI cards or similar, I can easily crunch through 200 tasks in ten minutes. There are many hosts with mining rig pedigrees that have multiple gpus. I have a minimum of 3 cards in every host.

Recently been having trouble getting new tasks, because some N-Body won't download - and I haven't opted for N-Body tasks for a couple of years? Is there a simple fix for this?

3/28/2019 3:03:11 PM | Milkyway@Home | Reporting 4 completed tasks
3/28/2019 3:03:11 PM | Milkyway@Home | Not requesting tasks: some download is stalled
3/28/2019 3:03:13 PM | Milkyway@Home | Scheduler request completed
3/28/2019 3:13:16 PM | Milkyway@Home | Sending scheduler request: Requested by project.
3/28/2019 3:13:16 PM | Milkyway@Home | Not requesting tasks: some download is stalled
3/28/2019 3:13:17 PM | Milkyway@Home | Scheduler request completed
3/28/2019 3:23:18 PM | Milkyway@Home | Sending scheduler request: Requested by project.
3/28/2019 3:23:18 PM | Milkyway@Home | Not requesting tasks: some download is stalled
3/28/2019 3:23:20 PM | Milkyway@Home | Scheduler request completed
3/28/2019 3:33:23 PM | Milkyway@Home | Sending scheduler request: Requested by project.
3/28/2019 3:33:23 PM | Milkyway@Home | Not requesting tasks: some download is stalled
3/28/2019 3:33:25 PM | Milkyway@Home | Scheduler request completed

Hey guys,

So the current set up allows for users to have up to 200 workunits per GPU on their computer and another 40 workunits per CPU with a maximum of 600 possible workunits.

On the server, we try to store a cache of 10,000 workunits. Sometimes when a lot of people request work all at the same time, this cache will run low.

So all of the numbers I have listed are tunable. What would you guys recommend for changes to these numbers?

Jake

<next_rpc_delay>600.000000</next_rpc_delay>

<scheduler_reply>
<scheduler_version>707</scheduler_version>
<dont_use_dcf/>
<master_url>http://milkyway.cs.rpi.edu/milkyway/</master_url>
<request_delay>91.000000</request_delay>
<project_name>Milkyway@Home</project_name>
<project_preferences>
<resource_share>10</resource_share>
<no_cpu>1</no_cpu>
<no_ati>0</no_ati>
<no_cuda>0</no_cuda>
<project_specific>
<max_gfx_cpu_pct>20</max_gfx_cpu_pct>
<gpu_target_frequency>60</gpu_target_frequency>
<nbody_graphics_poll_period>30</nbody_graphics_poll_period>
<nbody_graphics_float_speed>5</nbody_graphics_float_speed>
<nbody_graphics_textured_point_size>250</nbody_graphics_textured_point_size>
<nbody_graphics_point_point_size>40</nbody_graphics_point_point_size>
</project_specific>
<venue name="home">
<resource_share>50</resource_share>
<no_cpu>0</no_cpu>
<no_ati>1</no_ati>
<no_cuda>1</no_cuda>
<project_specific>
<max_gfx_cpu_pct>20</max_gfx_cpu_pct>
<gpu_target_frequency>60</gpu_target_frequency>
<nbody_graphics_poll_period>30</nbody_graphics_poll_period>
<nbody_graphics_float_speed>5</nbody_graphics_float_speed>
<nbody_graphics_textured_point_size>250</nbody_graphics_textured_point_size>
<nbody_graphics_point_point_size>40</nbody_graphics_point_point_size>
</project_specific>
</venue>
</project_preferences>

<result_ack>
    <name>de_modfit_sim19fixed_bundle4_4s_NoContraintsWithDisk260_3_1533467104_9447502_1</name>
</result_ack>
<result_ack>
    <name>de_modfit_sim19fixed_bundle4_4s_NoContraintsWithDisk260_1_1533467104_9241919_1</name>
</result_ack>
</scheduler_reply>

Jake -

I just did a "user request for tasks" and received 51 new ones.

As I have written before, every 4 minutes or so I complete a task, report it, request new tasks, and get nothing. I have about 200 tasks now from my user requests so I will have to wait until tomorrow and see if my stock pile bleeds down.

Looked through the forum, and couldn't find one. Does one exist?