Tasks mostly have a 10 day deadline, but some may be shorter.

For results to be useful, you need to return and report them well before the deadline.

Believe it or not, nearly all the settings can be set to inadvisable values. If you are not comfortable adjusting them manually, I recommend you use one of the WCG presets.

Using an intermediary device is theoretically possible, but causes all sorts of grief. Don't try it unless you have no option.

Hello Didactylos.

Fortunately, I am comfortable with adjusting the values for the parameters under the WCG Device Manager and I understand those parameters. The thing is what a limit value is for one setup or website may not necessarily be the same limit for another setup or website. I just can't find any point in not informing a user (else enforcing it) what the limits are.

BOINC does impose a limit: one cannot enter a value greater than 10-days under the Advanced > Preferences > Network usage > Additional work buffer. Again, I understood that the local preferences file (via the BOINC) is supposed to override the WCG website settings. But, in my case, for some yet unknown reason to me, it did not: the website setting of 14-days is the setting that over-rode the 10-day setting/limit for the work unit buffer. So WCG handed me a 14-days worth of buffer reflected in the 14-day deadline. Was there any impetus for me to rush out the workunits because that 14-days value may be too long as to be "inadvisable" as you put it? How would a user know that? How would a user know that a value is "inadvisable" as to cause major problems later when the website does NOT seem to think that the parameter-value is important enough to warrant spending effort to prevent users from input-ing an "inadviasble" value?

To the WCG tech group, please shed some technical light here. For one: why did the website value seem to have overriden the local (BOINC) settings (instead of the other way around) for the workunit buffer?

Thanks.

Hello Sekerob.

Your (Jul 3, 2009 7:43:55 AM) post was helpful in my effort to understand what may have happened relative to the concern of -- work units buffer not filling up the (correct) quota for any given case. We now have a good starting point to furthur close in on the issue.

For my BOINC (v6.2.28) client:
1. Yes, there were a number of "Reading preferences override file" messages.
2. No and I am sure of this: I did not click on the clear button. If ever I inadvertently clicked on that clear button, I am sure that I have set the local preferences again. As a matter of practice, I always check the preferences every after BOINC launches and then check them again (under the message log) to make sure that I have the line "Reading preferences override file" as the last message with no other contradictory messages before BOINC starts crunching work units.
3. No, I do not have the line "need to contact project" or something similar under the message log. Also, I do not think that there is an impetus for BOINC to "contact project" in as much as the network usage times (for my machine under the local preferences) was set to 14-days. In any case, there was no network connect attempts done either autonomously by BOINC or I doing it manually.
4. If the WCG server determined that my case went "over the limit", I say that the call was in error. If there was an overdue workunit, then the deadline set for it was in error. There was not one work units that have been synced-up after the 14-day deadline.

Every workunit that my machine crunched have been completed and uploaded before the stated 14-day deadline. All workunits carried a 14-day deadline. No downloaded workunits carry a deadline earlier than 14-days. I do not see why I was given a low count of 4 workunits (with a forced deadline of 1-day) when all evidence on hand suggest that the number was way off course for my case: I was doing fine with the 1st two batches. Again, if the 14-days deadline is too long, then again, why wasn't a lower limit imposed, else made clear to users?

The way the above facts shape up is that they point to a WCG side server error, a BOINC client error, or the communication of the two as far as their assessment (what you refer to as "learning point") of the actual completed workunits uploaded by a user vis-a-vis the work unit deadlines for a batch/quota of workunits.

Ideally, a user can have his/her machine connect online daily, and the WCG (server) program can be given a large space to operate on and learn. My case happen to be not that ideal -- the reason that I asked for the possibility of sync up with an intermediary device, say an USB thumbDrive.

WCG: for your comments and resolution, please.
]Thanks.

Hello Didactylos.

Your (Jul 12, 2009 2:13:27 AM) post was not helpful relative to the concern of -- work units buffer not filling up the (correct) quota.

•Your text:
"BOINC will attempt to contact WCG at least every 3 days, regardless of any other settings."
•Fact:
As I have stated in my post) which you have not obviously considered: "In any case, there was no network connect attempts done either autonomously by BOINC or I doing it manually."

•Your text:
"The only way you can know the deadlines for tasks is by looking at what the deadlines actually are. There is no contract or requirement or even guideline for what deadlines a BOINC project should set. Here, they are typically 10 days."
•Fact: I never had even a single instance of the supposedly typical 10 days (deadline). As I stated in my (Jul 12, 2009 1:45:34 AM) post: "Every workunit that my machine crunched have been completed and uploaded before the stated 14-day deadline. All workunits carried a 14-day deadline. No downloaded workunits carry a deadline earlier than 14-days".

•Your text: "If you set the network connection interval greater than the deadline, as apparently you did, then BOINC will be unable to schedule work properly."
•Fact: The work schedule was properly scheduled for the first two sync-up in my case. There, it was on the 3rd and later sync-ups that the scheduling was way off the mark.

•Your text: "The deadline is not related to the amount of work you are sent. Each task has its own deadline."
•Fact: The deadline is (or is supposed to be) related to the amount of work sent. That is true eveywhere and I don't think WCG's case should be an exception. Each task does have its own deadline and that deadline needs to take into account the time it takes for a machine to complete the total amount of work sent, which in turn depends on the network usage times/freq.
•Cpmment: I guess this is where the problem lies, and that is: the deadline is not related to the amount of work sent. If so, then the solution is straightforward: for WCG to relate the amount of work sent to the deadline.

Thanks for your time.