Alas, no good ANSWER, only ideas. Or...we could just limp along, and close out with this. I don't think the SETI team at Berkeley cares one way or the next. Either way they get their data, and close down the task of processing incoming data. perhaps occasionally throwing a little work around out there for those of us who don't just disconnect on that day.

Remember, the majority of people at SETI run Stock with a 10 day cache and have machines that in NO WAY resemble yours.

Also, just ignore the Fact that the only change to the Server was the quorum settings.

several things were changed at many different times. not sure why fact is worthy of a capital F.

device limits raised from 100/100->200/400 ~ December 7th 2019
device limits lowered from 200/400->200/300 ~ December 10th 2019
Server version changed from 709 to 715 ~ December 20th 2019
"change to the validator that raises the effective quorum for overflow results" ~ December 21st 2019
Server version changed from 715 to 709 + unnamed "fix" ~ December 26th 2019
device limits lowered from 200/300->150/250 ~ January 16th 2020
device limits lowered from 150/250->150/150 ~ January 16th 2020

Only 528 blc channels left to split, and then we can have some peace here :-)
Arecibo work will go away so quickly that we won't even notice when new Arecibo work is added.

Looks pretty Obvious to Me the lines start going up after Dec 21st. Why are you defending something that adds tasks to the database when the problem is tasks being added to the database? Are you married to that change to the point you can't let it go? If you remember a number of people couldn't get work when at Server version 715, it wasn't until the change back to 709 on the 26th that workflow resumed to normal. Where is Dec 26th on that chart?

Also, just ignore the Fact that the only change to the Server was the quorum settings.

Looking at my own task counts, there does seem to be an unusual discrepancy between what the server thinks I have in progress (2957), and what I can see locally (1742). Ghosts! When/if the server emerges from its typical morning constipation, I'll try to identify which computer(s) is/are most affected, and try my own ghost-busting technique.

Should see some improvement on March 23 cause that is when thousands of my quorum=1 tasks that validated back at the end of January will have my wingmen time out or finally report their tasks.

That should reduce the size of the database I would hope for the last week of Seti.

No outage again this Tuesday?

The SSP said: Replica seconds behind master 42,550