andzgrid, please refer to our previous replies, where these issues are discussed in full.

Thank you.

We can only repeat ourselves so many times.

I am sorry if you find this unsatisfactory.

Your questions have been answered, again and again, by myself, my colleagues, and other members. They have all given you the same advice.

Hello Didactylos.

Your text:
We can only repeat ourselves so many times. I am sorry if you find this unsatisfactory. Your questions have been answered, again and again, by myself, my colleagues, and other members. They have all given you the same advice.

My comment.
And what advice is that? Why not refer me to it for the last time and cite where or what I may have missed. Besides, who will answer the question "was my question answered?" You? I don't think so. If you look around most everywhere, I think that person will have to be me and I say that my questions (from specific issues I raised) were not answered to my satisfaction, certainly not from you. And please stop dragging everyone else as if you had permission to speak for them. Please speak only for your self.

Let us be specific. Where is the text in the posts earlier than this that answered my question: "What determines when a given WU's execution ends? Is this control coded in the WU itself?"

Besides, in case you have not noticed, I have never asked help from you in any of the posts here or earlier, nor anywhere else in WCG for that matter. If ever I expressly addressed a post to you asking for help, that must have been an inadvertent one.

If you do not feel inclined to help, I say do not. In fact, the way I see it, this thread would have brighter heads pitch in for ideas without you around.
.

The crux is the connect frequency as what BOINC is told to adhere to and what is communicated to the servers on each contact. The deadlines are 10 days for regular work, no discussion. Let the servers know through the SET connect pref that you will connect within 10 days again and you'll get a good lot of work buffered. The servers really do not care about past history, other than a value rated to establish if a client is reliable for:

A. valid results
B. has a low return time so it can be assigned rush/repair work (under 48 hours).

Past performance is no guarantee for the future, same as the share holder reports read.

As for scheduling, the local prefs allow to have a single weekly connect for day and hours, thus set the Connect every X days to default, think it's 0.1 or 0.2 and additional buffer to e.g. 8-9 days. The best automated extension you thus get is each 7th day. Set it higher and various safeties kick in that differ depending on client version. BOINC by rule aims to complete all work 24 hours before deadline. If it has more than that, it will switch to high priority processing, which than whole or partially blocks work fetch again. Define your requirements within these limitations and visit the Start Here FAQ's for a network scheduled connect sample for pointers on how to configure accordingly.

2 Euro cents, from me.

andzgrid,
The good news in your last messages is that your client can connect more often, and also for long sessions. If it had not been possible to connect at least once every 10 days, or to be safer, once every 9 days we would not have had any solution at WCG.

Let's first clarify an important point. You seem to think that you can work on x-day batches which would have one deadline attached to their whole content. You would load a big number of WUs, then process them offline, then upload all their results at once and report them, then load a new batch and so on.
Boinc client and server have not been designed this way. Their concept is that of a continuous flow of WUs, each with its own deadline and its own process cycle. The client asks for as many WUs as it computes are necessary according to your settings and your processing speed, the server sends them, they start to be processed immediately, and as the process of the first WUs progresses the client will ask for more WUs to keep the job queue at the correct size. When a WU is complete its result files will be uploaded immediately if a network connection is available, then it will become "ready to report" and it will be actually reported and made ready on the server side the next time the client requests more WUs.

The fact that this is designed as a continuous flow does not mean that you need to be connected permanently though. In fact the client will perform operations which need a connection as soon as it detects one. So if you connect after 2 days off line when the client will detect the connection it will immediately upload the result files of completed tasks and request new work for replacing them at the same time. The first time it will have no "ready to report" WUs to report, but at the next request for new work the WUs whose result files have been uploaded will be reported. The fact that your network sessions are long enough will ensure that the process works smoothly and you can also force an "update" before going off line for a long time to make sure that the last ready-to-report WUs are reported even if the client does not need new work at this time.

The client learns about its processing pace as time and process go. At the beginniing you will not receive 9 days of work even if you have set your extra work buffer at this value. But your stock of WUs will increase progressively as the client learns that it can ask for more work safely. One of its primary criteria is to ensure that WUs are returned early enough before their deadline, therefore if you "frighten" it by returning a bunch of WUs at the last limit or even too late (uploading and reporting hundreds of WUs at once takes a while) it will not "dare" to ask much work.

With the way you were working you were taking a serious risk to have WUs reported "too late" while they could have been returned and reported many days earlier.
With the continuous way new WUs which will be at the end of the queue will always have recently set due dates and will be able to wait longer.

This is what I suggest for restarting on a clean basis:
1. Open the Preferences window of your client and click on the Clear button
2. Also from the Advanced view of the client select Activity->Network always available
3. On the website display the profile attached to this machine (select My Grid->Device Manager, then click on the profile name of your machine)
4. In the profile window click on Maximum output at the top, then
5. Click on Custom profile to re-display the detailed settings
6. Check that the percentage of processor time is showing 100 %
7. Review your selection of projects to make sure it is as you like it and check the two boxes associated to this selection as you wish
8. In section Processor usage make sure that the % of multiprocessors is set to 100 %
9. In section Workunit cache settings leave or set the network value at 0.0 days and set the cache extra days value to 10 days
10. Do not forget to click on Save at the bottom of the Profile window
11. While you are still connected to the network, from the Advanced view of your client select the Projects tab, select the WCG line and click the Update button to force the client to receive the new Profile settings from the server.

From then on, keep your client connected as often and as long as you can. As I have said earlier it will probably take it several days to load a maximum of WUs, but at each network session it should normally load more, thus decreasing the idle time when you are obliged to stay offline for very long periods.
In any case make sure you have a long enough connected session at least every 9 days, otherwise your client might start to return "too late" WUs and it will reduce its requests for new work.

Keep us informed of the outcome, but be patient at the beginning. Jean.