There's an old saying "If you have nothing to say, then perhaps you should say nothing." At this point I think the first "nothing" needs to be modified, perhaps with "constructive" or even "intelligent".

Why don't you just use settings appropriate to your usage for each machine instead of whining that the project can't predict what you've studiously avoided specifying?

I'm pretty sure you know what you need to do and how to do it. It's nothing to do with anyone else.

If you really don't care, I'm pretty sure you wouldn't have wasted all this time typing what you have. So that's another thing that turned out untrue.

---

.
[snip]
.

Thanks for the reference and I may pursue it... Not sure because sometimes I also wonder if some of this is my own fault.
...
In addition, I just read a comment from Mod.Sense [who seems to be one of those people] to the effect that Rosetta@home isn't much worried about the bandwidth these days.

I also rather doubt that much will be done to address your bandwidth loss issue. Therefore ...

You have two goals: 1) to eliminate or minimize bandwidth loss and 2) maximize computer utilization. These two goals are not 100% compatible.

ASSUMPTION: you are only willing to process WUs from Rosetta

To minimize bandwidth loss, set preferences to have Rosetta send WUs of only 1 hour duration. Set WU storage parameters to 0+0, and use only a single thread on a computer that runs much of the time. The maximum bandwidth loss possible, then, approaches a single WU size.

This configuration however results in underutilization of the computer if it has more than 1 CPU without hyperthreading (or equivalent from AMD). To more fully use all the CPU/threads in multicore/hyperthreading CPUs increases the potential loss of bandwidth nearly linearly with each additional WU being processed in parallel. It also has the risk of not keeping the thread busy if/when WUs can not be downloaded immediately after completing a WU (Rosetta has no work to send, the internet is unavailable, maintenance or breakage, ...).

Addressing the second goal of keeping the computer 100% busy, then, requires accepting an increased risk of bandwidth loss. Increasing the WU store so one or more WUs are ready in the computer store allows some loss of availability of WU downloads without having the computer go idle. The larger the store, the longer the non-availability can be to keep the computer busy, and the larger the risk of bandwidth loss. That risk is very non-linear as the size (in days) of the store approaches the size of the time to the deadlines. Likewise, the longer the processing of a WU, the less often downloads must be done with very little change in the size of the WU itself (IIRC).

If the assumption made above is false, then a second approach can be taken, to wit, add a backup project(s) so that when the primary project does not have work or can not be contacted, the backup project(s) can send one to keep the computer busy. This approach helps assure the computer is 100% busy regardless of the choices made about WU size and days of storage made for the primary project (backup projects do not download into the store), and eliminates the need to monitor/adjust BOINC Manager frequently to keep things running.

A backup project is one for which the resource share is 0 (zero).

Users have to make their own decisions and choices that they believe are the best tradeoffs. I wish you luck in finding the best tradeoff for you.

---