I haven't caught the splitters getting back in action after they went offline several hours ago. Think whoever was shepherding them in the lab went home.

Thanks Jim - I was going to do a count later in the day.
One thing that I find less than helpful is that the SSP declares an average turnaround of 18 hours, ... what would be more helpful in this discussion would be to know the distribution of durations using a couple of "randomly" selected machines (obviously a sample of two is not statistically significant, but it would give an idea of what shape the curve is.).

Ideally there would be multiple tables (ie one for WUs, one for results, one for Hosts, one for user accounts etc, etc) and they are all linked to each other.

But unless we get an actual schema of the database, any guesses are little more than than wild speculation.

Ideally there would be multiple tables (ie one for WUs, one for results, one for Hosts, one for user accounts etc, etc) and they are all linked to each other.

But unless we get an actual schema of the database, any guesses are little more than than wild speculation.

That is exactly the way it is structured.

https://github.com/BOINC/boinc/blob/master/db/schema.sql#L241

That is exactly the way it is structured.

https://github.com/BOINC/boinc/blob/master/db/schema.sql#L241

... And just maybe release their wish list for better hardware that can handle the loads Seti will be dealing with in the future ...

Then re-release some of the BLC35s in small batches ...

Then re-release some of the BLC35s in small batches ...

Then re-release some of the BLC35s in small batches ...

If we're going to stress test it, we might might as well really stress test it.

Then re-release some of the BLC35s in small batches ...

If we're going to stress test it, we might might as well really stress test it.

I'd prefer to stress-test one problem at a time. We've got...

1) The concession to pester-power with the raised in-progress limits
2) The overdue server software update that was pulled because of Anonymous Platform
3) The faulty cards and drivers requiring extra verification
4) The noisy data from both Green Bank and Arecibo

... And just maybe release their wish list for better hardware that can handle the loads Seti will be dealing with in the future ...

Just savoring the irony of those messages last fall that the workload was increasing and they needed more folks doing more work to keep up with supply.
"Build it and they will come ..." or is that "Be careful what you asked for. You just might get it."?

The Return rate keeps falling, the Work in progress numbers keep falling, yet the Validation/Assimilation backlogs continue to grow.

I think they're just going to have to stop all work production, and let the servers sit for a week (or more) and let systems return the odd resend they get in order for the Validation backlog to clear, and then allow the resulting increased Assimilation backlog to clear (and hopefully the Deleters & Purgers won't develop a backlog).
Then reset the server side limits back to 100 + 100, pull all BLC35 files and not re-release them until both extra replication to handle the RX5000 series is reduced back to just 2 and they have their new storage server running, which will hopefully perform well enough even if all the data isn't cached.
Then re-release the BLC35s and see if the system grinds to halt again or not. And just maybe release their wish list for better hardware that can handle the loads Seti will be dealing with in the future (maybe get a second hand 2015 PowerEdge R730 server- supports 2 CPUs and 128GB of RAM per CPU?).

One thing I have noticed is that in the weeks following a holiday I see a fair number of computers that last visited the servers around the holiday time. These process a few tasks then vanish until the next holiday.

Thanks Jim - I was going to do a count later in the day.
One thing that I find less than helpful is that the SSP declares an average turnaround of 18 hours, ... what would be more helpful in this discussion would be to know the distribution of durations using a couple of "randomly" selected machines (obviously a sample of two is not statistically significant, but it would give an idea of what shape the curve is.).

Indeed tough to make good decisions lacking that sort of analysis. Would be interesting to see a graph of that, but again, server resources, and that type of db search is just more rocks on an overloaded wagon.

One thing I have noticed is that in the weeks following a holiday I see a fair number of computers that last visited the servers around the holiday time. These process a few tasks then vanish until the next holiday.