I added a 3 day grace period to the server configuration (<grace_period_hours>). Hopefully this will help otherwise I'm open to suggestions and feedback.

What about those who had work completed, but due to the DNS issues their work didn't make it through? I had two work units that finished Mar 2nd and were due Mar 3rd, but they never went through until the DNS issue was resolved, and are now showing "Too many total results" as the error.

I added a 3 day grace period to the server configuration (). Hopefully this will help otherwise I'm open to suggestions and feedback.

What about those who had work completed, but due to the DNS issues their work didn't make it through? I had two work units that finished Mar 2nd and were due Mar 3rd, but they never went through until the DNS issue was resolved, and are now showing "Too many total results" as the error.

Unfortunately those jobs with such errors will not be rescued but should eventually be given credit.

Unfortunately those jobs with such errors will not be rescued but should eventually be given credit.

Glad to hear eventually they'll be given credit ^_^

[quote] There seems to be a deep assumption in there somewhere that most of the clients are supposed to be running continuously for many hours at a time. (Some of mine do, and others don't.)

The client preferences (on the website side) have the option of creating multiple (separate) profile categories. You could set up one with shorter target run-times for your systems that run less frequently and another with longer run-times for systems that run more continuously. The available range is quite large, as low as 1 hour and as high as 24 hours.

Either way, it sounds like in your particular case the amount of work being cached may be set too high. The BOINC manager will adjust the cached amount over time to match the percentage of time BOINC is running per 24 hour period, but it takes time to adjust and any changes to the settings will take more than a few days to get applied. (This is the same reason why many people suggest that any changes in target run-times be made in smaller incremental steps).

---

**38 cores crunching for R@H on behalf of cancercomputer.org - a non-profit supporting High Performance Computing in Cancer Research