It seems that a lot of suggestion assumes that newbies etc will have a 24/7 connection (e.g. 1/wu/core/day) Sadly that assumption is not true especially in developing countries. Here in Malaysia I have friends who can only afford a DSL package measures in 60 hours a week. 2 hours a day. Not to mention some are still using dialups.

People should be given a reasonable cache to start with - not just 2 hours of work. And I think "loss" of WUs and bandwidth wastage are a little exaggerated now that the great AP outage is behind us. Most of my APs in cache are initial replications, not reissues.
____________

... DSL package measures in 60 hours a week. 2 hours a day. Not to mention some are still using dialups.

People should be given a reasonable cache to start with - not just 2 hours of work...

???

Boinc has been designed exactly for that type of scenario. Hence, you can set your 'expected' connection interval and also additionally set to keep an 'extra' amount of cache. Set those in your web preferences or on the client itself.

Depending on your circumstances, 'reasonable' values are perhaps to have no more than 10 days of cache. Longer than that and you risk not returning the WUs in time.

As the user, it is up to you how you balance keeping many WUs in the cache versus the risk of no credit for WUs that are returned late.

For the project, if you do have an always on 24/7 connection, then a minimum sized cache minimises the 'administrative' loading on the project servers. For example, I have just 0.1 days set for my cache. Then also, I also run Climate Prediction...! (Very big long WUs.)

You have a choice, and great opportunity to 'play' with the settings.

Aside: Note that at the moment, the servers appear to be struggling to keep pace with WU requests. You may not get a big cache on your first attempt simply because the WUs are not available, or because the servers are overloaded by many requests from others.

Hope that helps,

Good luck!
Martin
____________
See new freedom: Mageia4Linux Voice See & try out your OS Freedom!
The Future is what We make IT (GPLv3)

Yep, actually I am in favour of keeping the current setup - a new client can get about 20 MB WUs on the second try (1st try somehow always give 1)

My comment was a response to suggestions (that seems to persists across threads - generally came about after great AP debacle where millions of AP Wus meet untimely ends and resends)that newbies and new clients be given very limited work in order to avoid losing a largish cache in case they dont come back (or scared off by a long queue of AP works), but for me personally the current setup is exactly fine - sometimes I do travel to rural areas with no internet access and the long queue options works great.
____________

... DSL package measures in 60 hours a week. 2 hours a day. Not to mention some are still using dialups.

People should be given a reasonable cache to start with - not just 2 hours of work...

???

Boinc has been designed exactly for that type of scenario. Hence, you can set your 'expected' connection interval and also additionally set to keep an 'extra' amount of cache. Set those in your web preferences or on the client itself.

Depending on your circumstances, 'reasonable' values are perhaps to have no more than 10 days of cache. Longer than that and you risk not returning the WUs in time.

As the user, it is up to you how you balance keeping many WUs in the cache versus the risk of no credit for WUs that are returned late.

For the project, if you do have an always on 24/7 connection, then a minimum sized cache minimises the 'administrative' loading on the project servers. For example, I have just 0.1 days set for my cache. Then also, I also run Climate Prediction...! (Very big long WUs.)

You have a choice, and great opportunity to 'play' with the settings.

Aside: Note that at the moment, the servers appear to be struggling to keep pace with WU requests. You may not get a big cache on your first attempt simply because the WUs are not available, or because the servers are overloaded by many requests from others.

Hope that helps,

Good luck!
Martin

You can also limit your network availability to specific times, so someone restricted to 60 hours/week could limit network access to 2 hours/day, and be sure they had plenty of time left over for other use.

... and as long as the user proved reliable, the cache can be allowed to build quickly, then any "newbie limit" becomes a non-issue.
____________