It started about a week ago, BOINC would Report completed tasks to SETI but would not fetch new work.

1/24/2010 10:58:13 AM SETI@home Sending scheduler request: Requested by user.
1/24/2010 10:58:13 AM SETI@home Reporting 1 completed tasks, not requesting new tasks
1/24/2010 10:58:18 AM SETI@home Scheduler request completed

I updated BOINC to the latest Rev with out success.

I tried turning the fetch function off then on but no change.

I have now run out of work for SETI.

My preferences are set to 10 day work buffer with a connect each day.

I am still getting work from Milkyway but it is limited to only 6 work units with no regard for processing time.

Whats gone wrong?

Why won't BOINC fetch work from SETI?

---

Does Seti ask for work if you suspend Milkyway?

Claggy

Are you signed on at SETI as "Castor River Railroad"? Then there your question has been answered pretty well. :-)

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

Not necessarily. Regulars will know that I have been testing BOINC pretty hard, with special reference to SETI and CUDA, for about a year now. I still don't think it's working properly.

Last week, I had to mess around with my test rigs to investigate some AQUA/BOINC/CPDN issues. That involved dropping back to BOINC v6.10.21 to finish off some incompatible CPDN tasks. The last one finished on Friday morning: I ensured that all three of my test rigs were upgraded back to v6.10.29, SETI CUDA work enabled, and CUDA long-term (work fetch) debt zeroed. Then I went away for a couple of days.

I left the hosts with a 12-hour cache setting (I keep it low-ish for testing), and freedom to fetch work as and when needed (always-on DSL router). I checked that all was running well at about 13:00 UTC Friday 22 Jan.: I got back home at 18:00 UTC today Sunday 24 Jan. to find all three CUDA cards idle.

From logging, I can see that the CUDA queues ran dry at 10:05:16 24/01/10, 12:01:29 24/01/10, and 21:40:58 23/01/10 (recording the times before the log rotates). In all three cases, CUDA debt had built up to well over 100,000 seconds, and clearly inhibited work fetch when they passed the 86,400 second "overworked" mark. I zeroed CUDA LTD for SETI (only - I have a tool for that) and new work was downloaded immediately.

I also have a tool which logs all BOINC debts even when I'm away. Tomorrow, when I have more time to investigate in detail, I will compare the "overwork" crossing points with the last work fetch times of 23 Jan 2010 10:53:21 UTC, 23 Jan 2010 5:51:52 UTC, and 22 Jan 2010 23:42:54 UTC (again recording for my own reference!).

First conclusion: "overworked" is being given higher priority in work fetch considerations than "GPU idle", which I think is the wrong way round. Second assertion, which will need further monitoring and analysis before it becomes a conclusion, is that long-term debt is still being built up too rapidly. Await further reports on boinc_alpha later in the week.