It is interesting to note that the assimilation backlog (which has bee averaging 400k lately) started when the replica was brought back online.
The Assimilation/Replica graphs look very similar over time.

---

Its alive!!!!

Well, the forums at least.

---

Seti@home classic: 1,456 results, 1.613 years CPU time

(:

---

It is good to see the system back. Thanks to the people who work so hard to keep this system going. It is going to be a rough recovery after such a long down time.

Woo Hoo Finally!
I received a single teaser task.
LMAO
EDIT: That fun lasted a whole 79 seconds :(

---

Place a big mark in your diary, and frame the task ;-)

---

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

3,866,416 ready to send ??!!

ok back to a normal 808,351

Even though I finally got through to the scheduler and got no tasks, should this be a concern --

02/13/2019 09:34:19 | SETI@home | Requesting new tasks for CPU and NVIDIA GPU
02/13/2019 09:34:19 | SETI@home | [http] HTTP_OP::init_post(): http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
02/13/2019 09:34:19 | SETI@home | [http] HTTP_OP::libcurl_exec(): ca-bundle set
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Connection 723 seems to be dead!
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Closing connection 723
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: TLSv1.2 (OUT), TLS alert, Client hello (1):
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Connection 721 seems to be dead!
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Closing connection 721
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Connection 722 seems to be dead!
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Closing connection 722
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Trying 208.68.240.126...
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Connected to setiboinc.ssl.berkeley.edu (208.68.240.126) port 80 (#724)

---

I don't buy computers, I build them!!

Look at your task-overwiew - the/my last 550 WUs marked as bad - joy in the day ;-)
Klaus

126 is the Scheduler and that is probably just an indication of a lot of traffic hitting it.

---

Even though I finally got through to the scheduler and got no tasks, should this be a concern --

02/13/2019 09:34:19 | SETI@home | Requesting new tasks for CPU and NVIDIA GPU
02/13/2019 09:34:19 | SETI@home | [http] HTTP_OP::init_post(): http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
02/13/2019 09:34:19 | SETI@home | [http] HTTP_OP::libcurl_exec(): ca-bundle set
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Connection 723 seems to be dead!
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Closing connection 723
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: TLSv1.2 (OUT), TLS alert, Client hello (1):
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Connection 721 seems to be dead!
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Closing connection 721
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Connection 722 seems to be dead!
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Closing connection 722
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Trying 208.68.240.126...
02/13/2019 09:34:19 | SETI@home | [http] [ID#1] Info: Connected to setiboinc.ssl.berkeley.edu (208.68.240.126) port 80 (#724)

. . I wish I knew. Are you using a proxy ??

Stephen

?

I've managed to send back all my completed tasks (from the two biggest systems). but getting project has no tasks available. so it seems they haven't opened the door yet.

Set NNT, and you'll be able to report old tasks and will get you past the "HTTP internal error". you do not need to wait the 5min timer for reporting tasks. just click "Update" over and over until all of your old tasks are sent back. I set max_tasks_reported to 250. even thousands of tasks only takes a few mins to report them all.

then wait patiently for more work lol.

---

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

I have a few tasks starting to come in now.

i got 15 on one update on one system, and maybe some more on a slower system. trickling in it seems.

---

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

I see the problems are continuing....
Scheduler allocation of work is sporadic, at best. At worst, it's hours between getting any work allocated (regardless of how much is there to be had).....

Actually this problem goes back Years, it's just for the first couple of Years there were few people reporting about the problem. Logs were posted, for years, showing how the Scheduler was simply ignoring work requests and just sending a few random tasks ever so often. It first started with the introduction of the BLC tasks in 2016. Finally enough people were reporting the problem that a serious attempt was made to solve the problem. It was found that as long as there was just One type of task in the cache there wasn't a problem, the problem started as soon as a different type task was added to the cache. At this point the cache was mainly filled with BLC tasks, and only a couple Arecibo files would be added per a week.

It was found the problem was solved by sending Arecibo VLARs to the GPUs and this seemed to work, as long as there are only a Few Arecibo Files split a week. Recently Many More Arecibo Files have been added to the cache than just a couple a week, in fact, there is a constant supply. Now, the Exact Same Problem has returned, the exact same problem which has been present for Years. It would seem the process that chooses which task to send hangs at some point and No task is chosen to be sent. As long as there is just One type of task in the cache, the problem doesn't appear. This is how BETA Works BTW. Only One type of task is in the cache at one time, for the past few weeks BETA has only been sending Arecibo tasks. When that file is finished at BETA, probably, a BLC File will be loaded, again, One type of File present in the cache at one time.

I'm willing to bet that if there were only One type of File in the SETI Main cache the recent Scheduler problems would disappear, just as has been the case for Years.
Hopefully those 'Lost' Arecibo files will be finished SOON and we will go back to having only a couple of Arecibo Files a week. Or, someone could manually Stop the Arecibo Files long enough to determine if that is indeed the problem.

I just have finished reporting. Got a few tasks in download pending with stuck and slow tasks.

---

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

A proud member of the OFA (Old Farts Association)

much needed db purging is happening ... from 9 million down to 7 million and hopefully lower. I think splitting, and giving out WUs will get better once the db purging is not the main focus.

I wouldn't blame the scheduler exactly for having problem with multiple WU types. More that its decision time for allocating tasks increases under high server loads causes timeouts - http or data reads.

Also it seems to have a load watchdog, where as now, it likes to only give 1 task at a time per computer thread for downloads. Likely due to too many dropped calls to it.

---

I am currently getting pretty much gpu tasks with very few or no cpu tasks.

Tom

---

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

I am currently getting pretty much gpu tasks with very few or no cpu tasks.

Pretty much normal.
Indulging in our favorite guessing game, I'm guessing that if you request both GPU and CPU work, it will class the work as GPU unless it can give you enough to fill the GPU cache and get a start on CPU's needs. At least, that seems to be what I consistently see here. Would only make sense.

---