Your problem with the estimates is you're using app_info.xml, possibly also including a <flops> in your app_info.xml. The automatic adjustments of server-estimates doesn't work in this scenario, meaning as long as you're using app_info.xml the only way to get better estimates is to manually set the <flops> to whatever is "correct" in app_info.xml yourself.

If you're not using the anonymous platform-mechanism on the other hand, the server-estimates would work and give you more correct estimates, except for new computers or in case of new application-versions will the server-estimates be off until enough work has been validated.

BTW, since they're already up to v7.0.44 the 7.0.42 will never make it to recommended.

Twylith, glad you now got a reasonable cache and sorry for having to rush off, but it would have been heck to pay if I had not joined the dinner table in time :D

With v7, for certain conditions such as stopping work fetch for a project could invoke things as EDF and does also kick off "Report Results Immediately". The MinB setting of anything near or over 2 days will kick of EDF... with 4 day deadline tasks the client wants to cram all queued tasks into 2 days... 4 days cache minus 2 days MinB (aka Connect every). The logic I've tried discussing with developers, particular when the client remains connected to the internet, but the behavior is still as per the old "connect about every..." the client assumes that the next connect wont be in another 2 days, by which time the 4 day deadline tasks are already 2 days old, and then it could be too late for the next scheduled connect in another 2 days.

Want to big time cache up at WCG and not have panic, set MinB to for instance 7-8 days [tested that few days ago to find the maximum in progress for WCG with 7.0.44], fill up, see panic start evolve, and when buffer has reached desired level, drop the MinB back to zero, and panic stops. This client has been out of reliable, with intend, so I can cache up and go to places where there is no internet for longer and not get 4 day deadline repair jobs.

At any rate, was asked by mail what I thought was the most irritating thing in the v7 client and made my pitch again. Who knows... if we select "Network always available" in the activity menu that I'd consider a signal, that MinB is just that and not some scheduling interval value. We'll see.

edit: Don't know what science you're running but if it includes HCC with 4 day cache as MinB setting, you're looking at 7 days deadline minus 4 days connect interval, is 3 days to report all work buffered. The oldest in buffer will be near 4 days old by the time it gets it's turn, and then... you get the incomprehensible stuff... logic most can't follow, including me. Resistance is futile with some BOINC matters... accept and move on.

With Minimum Work Buffer [MinB] of 2 days and Maximum Additional Work Buffer [MaxAB] of 4 or 6 or 8 days, does not matter, you'll be fine. As you've found, the MaxAB gives very little extra work over the Minimum value, which is because as I mentioned, WCG gives little work in one work fetch [officially maximum of 15 tasks per call]. Every time the buffer drops below 2 days minimum a call is made and as soon as total work goes over that minimum, be it receiving 1-10-100 tasks [however many the feeder has and can/will release of your selected sciences], fetching stops until the next time the total buffer drops again below 2 days. This repeats ad infinitum.

Since my hosts specify only a MinB, the backfilling is quasi constant, one or two tasks at a time. In the below sample a call is made for 35 seconds of work. Since there are no such short tasks, got one for 48433 seconds. That will be the time divided by the number of threads on the host until the next time the Minimum level is reached and a new call is made. In this case of a quad, approximately 12100 seconds or about 3.5 hours it will take before the cycle repeats.

922 World Community Grid 1/13/2013 7:30:31 PM [sched_op] Starting scheduler request
923 World Community Grid 1/13/2013 7:30:31 PM Sending scheduler request: To fetch work.
924 World Community Grid 1/13/2013 7:30:31 PM Requesting new tasks for CPU
925 World Community Grid 1/13/2013 7:30:31 PM [sched_op] CPU work request: 35.00 seconds; 0.00 devices
926 World Community Grid 1/13/2013 7:30:36 PM Scheduler request completed: got 1 new tasks
927 World Community Grid 1/13/2013 7:30:36 PM [sched_op] Server version 701
928 World Community Grid 1/13/2013 7:30:36 PM Project requested delay of 11 seconds
929 World Community Grid 1/13/2013 7:30:36 PM [sched_op] estimated total CPU task duration: 48433 seconds
930 World Community Grid 1/13/2013 7:30:36 PM [sched_op] Deferring communication for 11 sec
931 World Community Grid 1/13/2013 7:30:36 PM [sched_op] Reason: requested by project

I have noticed that the Results Status page is coming up a lot faster now. With 990 pages of results (currently) it had been very slow.