So some are getting tasks?

I am not. Yet.

Tom

---

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

All reported but nothing coming in.

---

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

A proud member of the OFA (Old Farts Association)

So some are getting tasks?

I am not. Yet.

Tom

. . Nor I ..

Stephen

starting to trickle in over here. got my first batch of 11 lol.

---

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

. . Damn, I finally got 2 whole tasks and they won't download ... :(

. . Out of work very soon ...

Stephen

:(

Full cachies :)

---

ATM downloading is an issue here also.

---

ATM downloading is an issue here also.

Same here.

---

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

A proud member of the OFA (Old Farts Association)

Looks like the downloads are getting unstuck. Starting to refill caches.

---

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

A proud member of the OFA (Old Farts Association)

Mine refilled up quite quickly here. :-)

Cheers.

My caches have refilled, but 3 splitters are offline [As of 12 Dec 2018, 3:50:04 UTC]

---

~Chris

My caches have refilled, but 3 splitters are offline [As of 12 Dec 2018, 3:50:04 UTC]

Maybe those were the ones that were causing the splitting errors earlier.

---

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

A proud member of the OFA (Old Farts Association)

Mine refilled up quite quickly here. :-)

Cheers.

. . Maybe I should move to the highlands ... :)

Stephen

:)

One possible explanation of that is the client request behaviour.

1) If the client requests work, and gets none, it goes into (increasing) backoffs
2) If the client requests work, and gets some, it's free to ask again
3) If the client completes an allocated task, all backoffs are cleared, and it can report the completed task immediately and request more work at the same time.

Collectively, these mean that if you're completely dry, it takes ages to get started.

But if you have a few dregs to complete, or you get a few tasks at an early request, you have a much better chance of asking, and asking, and asking, until you get more.

But, alas, it gets even worse when one has two projects running on the same host. When, for example, the Seti cache runs empty then the "other" project is free to fill the cache to capacity and the host will not even ask for more Seti work because the cache is full. Today I forgot to set Einstein to NNT while the Seti maintenance took place; as a result I have 58 Einstein GPU tasks and 95 Einstein CPU tasks in the cache. The good news - Einstein GPU cache is (roughly) 58 hours of work with a 14-day deadline so Seti scheduler is picking up enough GPU work to keep busy; the bad news - Einstein CPU cache is (roughly) 760 cpu-hours with a 12-day deadline, i.e. heavily over-committed, and in this condition the host/client will not even ask for any CPU tasks. (Resource allocation Seti/Einstein 92%/8% and cache limits of 1.0+0.5) Of course this is NOT a SETI server problem. It is just the way Boinc Manager works. After the 12 days have passed, the cache will fall under the configuration limit and Seti CPU work fetch will resume - unless I forget again(!) to set Einstein NNT on Tuesdays to stop this cycle. My hunch - having not looked at the boinc-mgr code - is that the project work fetch considers only the cc_config count of cores/cpus and does not look at the resource allocation, with the result for me that Einstein fetches 12 times more tasks that it really should. (Long ago there was a thread elsewhere regarding exactly what "resource allocation" should do.)

I have been admonished many times to "not try to micro manage Boinc Manager." But sometimes I just can't help myself.... :(

---

I have been admonished many times to "not try to micro manage Boinc Manager." But sometimes I just can't help myself.... :(

When I end up with lots of Eienstein@home I simply go to NNT period. Not even letting it run during maintenance. It probably doesn't "help" but at least the tasks don't keep refiling.

Tom

---

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

The replica database lag is making a VERY slow crawl downwards after the outage. I think for it to reduce to zero is going to need one of the cron job glitches in the other server processes.

---

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

A proud member of the OFA (Old Farts Association)

The replica is almost caught up. Should be easier to view your tasks now.

---

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

A proud member of the OFA (Old Farts Association)

Now, if only the Validator would get on top of things...

---

Grant
Darwin NT

Seems to be happening again,

Thu Dec 13 16:48:52 2018 | SETI@home | Project has no tasks available
Thu Dec 13 16:54:06 2018 | SETI@home | Project has no tasks available
Thu Dec 13 16:59:20 2018 | SETI@home | Project has no tasks available
Thu Dec 13 17:04:35 2018 | SETI@home | Project has no tasks available
Thu Dec 13 17:09:49 2018 | SETI@home | Project has no tasks available
Thu Dec 13 17:15:04 2018 | SETI@home | Project has no tasks available
Thu Dec 13 17:20:14 2018 | SETI@home | Project has no tasks available
Thu Dec 13 17:25:23 2018 | SETI@home | Project has no tasks available
Thu Dec 13 17:30:42 2018 | SETI@home | Project has no tasks available
Thu Dec 13 17:35:56 2018 | SETI@home | Project has no tasks available

Cache is down by about 150 tasks already.

I'm getting work again.