Some R@h users appear to be doing something similar. I am routinely seeing workunits which had an earlier failed task on somebody else's computer which timed out. (Remember: The reporting deadline is 3 days. Hence, don't buffer more than can be completed in 3 days.)
Tip: Increase the "Target CPU run time" from the default 8 h to more.
Rosetta@home preferences
Then the same number of downloaded tasks will last you longer. While browsing top_hosts.php, I saw that one of the prolific users set it to 24 h even (which may be a bit much, but works too of course).
Some notes on the process of changing "Target CPU run time":
1. It used to be that the boinc client was oblivious to these changes which are made at the server, and continued to put the old task duration as estimated task durations of new tasks. (In effect, the client would buffer too much after the target run time was increased, or vice versa would buffer too few after the target run time was decreased.) The client's estimation only gradually converged to the new run time while more and more tasks completed with the new setting.
I don't know if this problem still exists.
2. When said change is made on the website, which tasks exactly are affected by the new setting? Well,
somebody once wrote:
After a scheduler request of the client (e.g. a project update), the target run time of the following tasks is being modified:
+ tasks which hadn't been started yet (and are started after the scheduler request), this of course also includes tasks which are yet to be downloaded,
+ tasks which were suspended to disk (and are resumed after the scheduler request).
The target run time of the following tasks are
not modified:
–tasks which are running during the scheduler request,
–tasks which were suspended to RAM during the scheduler request.
Edit, I forgot:
3. For the time being, "Target CPU run time" is recognized only by the "Rosetta" and "Rosetta mini" applications, not by "rosetta python projects".