Still No Work at Beta. Tasks ready to send = 0

I finally got my latish model Android phone setup to crunch for Beta so someone hopefully could get us some updated tasks that would run on late model Androids.
Its been "waiting for work, nothing to do" for "several" days now.

Tom

Ah, now I see said the blind man. My late model Android phone blew through 99 beta site errors so the scheduler won't send me any more for a while. Maybe it will give the Android Dev something to change.

Tom

---

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

The server status page is showing many processes disabled. Not sure what is going on.

Houston, we've had a problem ...

---

And we're back

---

The server status page is showing many processes disabled. Not sure what is going on.

"'This must be Thursday,' said Arthur to himself, sinking low over his beer. 'I never could get the hang of Thursdays.'"
--- Douglas Adams, The The Hitchhiker's Guide to the Galaxy

(Or was it Thorsday?)

---

The unplanned outage did not help the situation. The splitters are slow and the RTS is down to 68k. Hopefully everyone has full caches at the moment, and we will only get a depletion of our own caches and not a run dry situation. Since the system is working (though not optimally) I don't think there is much to do but muddle through and hope things get better.

I still think some longer lasting WUs would help.

Looks like the file deleters have given up, and due to that backlog the splitters are struggling even more than they were just after the weekly outage.

Maybe time to see if the new upload server (and the other processes it runs) would help things out here on Main?

---

Grant
Darwin NT

WU delete backlog continues to grown, and the splitter output has just taken a dive, but recovered back to it's better than zero output a few minutes later.
The noise bombs mixed in with the shorties certainly aren't helping things.

---

Grant
Darwin NT

WU awaiting deletion continues to climb, but with the Return rate lower than it's been the splitters have been able to pump out a bit more work than they have been.

---

Grant
Darwin NT

3649588606

8042499883	7019416	12 Sep 2019, 14:46:25 UTC	14 Sep 2019, 1:50:18 UTC Terminé et validé	2,208.81	322.94	66.57	SETI@home v8
Plateforme anonyme (GPU ATI)
8042499884	8813875	12 Sep 2019, 14:46:34 UTC	5 Nov 2019, 6:37:30 UTC	Terminé et validé	1,285.38	123.20	66.57	SETI@home v8 v8.00 (cuda42)
windows_intelx86
8201281661	8555278	5 Nov 2019, 0:11:05 UTC	      28 Dec 2019, 5:10:47 UTC	     En cours	   ---	---	---	SETI@home v8 v8.22 (opencl_ati5_SoG_cat132)
windows_intelx86

Wu validated but sent to third wingmen

---

3649588606

8042499883	7019416	12 Sep 2019, 14:46:25 UTC	14 Sep 2019, 1:50:18 UTC Terminé et validé	2,208.81	322.94	66.57	SETI@home v8
Plateforme anonyme (GPU ATI)
8042499884	8813875	12 Sep 2019, 14:46:34 UTC	5 Nov 2019, 6:37:30 UTC	Terminé et validé	1,285.38	123.20	66.57	SETI@home v8 v8.00 (cuda42)
windows_intelx86
8201281661	8555278	5 Nov 2019, 0:11:05 UTC	      28 Dec 2019, 5:10:47 UTC	     En cours	   ---	---	---	SETI@home v8 v8.22 (opencl_ati5_SoG_cat132)
windows_intelx86

Wu validated but sent to third wingmen

Now this was your fault by returning that work unit late, Report deadline 4 Nov 2019, 19:46:16 UTC - Received 5 Nov 2019, 6:37:30 UTC, so by missing the deadline you triggered a resend. It's just a shame that that resend will gain no credit for that person.

Cheers.

7019416 is my host ^^ received the 9-12 sent the 9-14 ;)

---

I'm sorry, it was your wingman's fault, but you should understand now about what happens when someone returns after a deadline has passed.

Cheers.

But no harm done. All received the same credit. Just a waste of processing time.

Task
click for details	Computer	Sent	Time reported
or deadline
explain	Status	Run time
(sec)	CPU time
(sec)	Credit	Application
8042499883	7019416	12 Sep 2019, 14:46:25 UTC	14 Sep 2019, 1:50:18 UTC	Completed and validated	2,208.81	322.94	66.57	SETI@home v8
Anonymous platform (ATI GPU)
8042499884	8813875	12 Sep 2019, 14:46:34 UTC	5 Nov 2019, 6:37:30 UTC	Completed and validated	1,285.38	123.20	66.57	SETI@home v8 v8.00 (cuda42)
windows_intelx86
8201281661	8555278	5 Nov 2019, 0:11:05 UTC	9 Nov 2019, 14:02:29 UTC	Completed and validated	1,976.42	397.70	66.57	SETI@home v8 v8.22 (opencl_ati5_SoG_cat132)
windows_intelx86

---

WU awaiting deletion continues to climb

It could just be me but it seems the new average is between 5.4 and 5.6 million work units waiting deletion. From where I sit the server seems to be handling this quite well or am I missing something?I am gathering it is sitting a little higher than normal because of the fast return rate in saying this though I have seen very few noise bombs a.k.a. -9 overflow

---

The db purging can get large and not have issues until approaching 10 million or so.

The WU lines in the status should be small though, like they are right now. The WU files waiting for deletion has been over 1 million recently, and that is out of the ordinary and something to keep an eye on.

Workunits waiting for validation 0 1 523 9m
Workunits waiting for assimilation 0 0 68,929 9m
Workunit files waiting for deletion 0 0 1,728 9m
Result files waiting for deletion 0 0 664 9m

Luckily it looks like the system has recovered and is doing much better at the moment.

WU awaiting deletion continues to climb

It could just be me but it seems the new average is between 5.4 and 5.6 million work units waiting deletion. From where I sit the server seems to be handling this quite well or am I missing something?I am gathering it is sitting a little higher than normal because of the fast return rate in saying this though I have seen very few noise bombs a.k.a. -9 overflow

WUs Awaiting deletion normal level, regardless of return rate, should be 0 (or very close to it). The highest it has ever got is 4.06million, although this time it hit the number 2 position with 1.47 million.
In progress tends to vary from 4.6 to 5 million.
Results awaiting purge varies between 2 to 6 million, depending on what issues the servers are having at the time.

---

Grant
Darwin NT

Has anybody noticed that the Server Status clock is exactly 24 hours fast?

I point this out because I do not know how the server it runs on, and any other software running on that server, interface with SETI and, perhaps, even BOINC itself. However, as a DT person, I know that a clock error like this has the potential of causing serious problems, not only with the proper triggering of tasks, but even serious data corruption. An error like this can be especially serious in scientific research, where incorrect timestamps can destroy the credibility and validity of data.

I hope this is just a minor problem. Does anyone know the exact interface of this server with everything else? If so, please evaluate the possible impact. If no one knows for sure, then I recommend someone with immediate access to the staff notify them as soon as possible in case this situation is serious.

Thanks.

Which clock do you mean?

When I look at the Server Status page, at the top it says “ As of 14 Nov 2019, 2:20:05 UTC”. Which was about 15 minutes ago.

---

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

The server status page shows UTC time. It is correct.

---

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

A proud member of the OFA (Old Farts Association)