From Asteroids@home's server status (daytimes are European):
- during the entire Thursday: 320,000 tasks in progress
- Friday noon: 290,000 tasks in progress
- Friday night: 240,000 tasks in progress
So on Thursday, while a whole lot of people bunkered, the number remained constant, which makes sense. On Friday, when most people went online again, the number steadily declined by a rate of 80,000 per day.
In addition, tasks where available on Thursday only before ~08:00 AM UTC, and on the entire Friday at a very low rate. IOW while tasks in progress declined, tasks ready to send did not increase but remained near zero.
Conclusions:
- If this goes on, there will not be many tasks in progress left towards the end of the sprint.
- If it is true that the server is set up to limit the rate of generated work according to disk space left, then the disk space is steadily decreasing.
- Yet results are being returned, tasks validated, WUs completed. Hence, the disk space is most likely being eaten up by the results.
Earlier I thought that the disk space reservations for tasks in progress were the cause for the disk space problems. But now it rather looks to me that the absence of administration, and lack of effective automated housekeeping, are Asteroids@home's problem.
They mentioned that they want to deploy new server hardware in Summer. All of the above lets me think that new hardware will at best paper over their problem in the short term, but not actually solve it. (Except if the new hardware also allows them to implement effective automated housekeeping.)