I was messing around with an old core 2 quad motherboard that had four x1 slots and one x16 slot. Fresh install of windows 10 and with five rx-560s.

All seemed fine***, I had 4 seti v8 ati tasks running and messages said it was too soon to get additional tasks for the other GPU. I then went to my account and allowed CPU tasks in addition to GPU. I set ngpu to 1.0 and ncpu to 0.4 so as to free up exactly 2 cpus for seti cpu work units.

I got over 100 cpu tasks downloaded all of which were stuck in transfer. CPU and GPU usage showed nothing happening. After a few minutes of nothing happening, I issued a --quit to boinccmd. That did not work so I rebooted.

Reboot did not solve any of the stuck transfers, I aborted all the transfers and reset the project. Right now I have 5 collatz running at %10 priority and hopefully seti at %100 will change its mind and download some more. Last I looked I saw "last request too recent"

***was not fine at first but that is subject of another post.

I was messing around with an old core 2 quad motherboard that had four x1 slots and one x16 slot. Fresh install of windows 10 and with five rx-560s.

All seemed fine***, I had 4 seti v8 ati tasks running and messages said it was too soon to get additional tasks for the other GPU. I then went to my account and allowed CPU tasks in addition to GPU. I set ngpu to 1.0 and ncpu to 0.4 so as to free up exactly 2 cpus for seti cpu work units.

I got over 100 cpu tasks downloaded all of which were stuck in transfer. CPU and GPU usage showed nothing happening. After a few minutes of nothing happening, I issued a --quit to boinccmd. That did not work so I rebooted.

Reboot did not solve any of the stuck transfers, I aborted all the transfers and reset the project. Right now I have 5 collatz running at %10 priority and hopefully seti at %100 will change its mind and download some more. Last I looked I saw "last request too recent"

***was not fine at first but that is subject of another post.

We all have had trouble with stuck downloads. It is not the fault of the way you are setup.

There are a couple of things you can try. Select the last of the stuck downloads and hit the retry button.

If you are running multiple projects on a box, you can also change the maximum file transfers to say, 16 and the maximum project transfers to say 8. That way, when Seti gets stuck (again) the other project will not get hung.

Another thing to do is put an upper limit on the "reporting tasks", say 100 or 250. This will help in that when you report a lot of tasks after a Seti outage (and/or on tuesday) it doesn't jam up your reporting. Until you have reported successfully, Seti will not download more tasks.

Sometimes you have to do a manual update to get it to "report".

When you run a lot of gpu's the behavior of the uploads/downloads reliability is more cranky.

Tom

---

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

We all have had trouble with stuck downloads. It is not the fault of the way you are setup.

There are a couple of things you can try. Select the last of the stuck downloads and hit the retry button.

If you are running multiple projects on a box, you can also change the maximum file transfers to say, 16 and the maximum project transfers to say 8. That way, when Seti gets stuck (again) the other project will not get hung.

Another thing to do is put an upper limit on the "reporting tasks", say 100 or 250. This will help in that when you report a lot of tasks after a Seti outage (and/or on tuesday) it doesn't jam up your reporting. Until you have reported successfully, Seti will not download more tasks.

Sometimes you have to do a manual update to get it to "report".

When you run a lot of gpu's the behavior of the uploads/downloads reliability is more cranky.

Tom

was not aware of these options. Normally I check to see if there is any bytes/sec at all. If not then I retry the one at the top unless it has a humongous size. Setting max number of files is better. This system had only 4 cores of which all were used %100 which contributed to the problem.