Judson, you are right when things are stable, but let's take a simple example to help figure things out better.

Take a single core computer steadily running tasks from a given project in 4 hours.
You are right thinking that it will ask for a new task every 4 hours, whatever its cache size.
The only difference will be the number of jobs in the queue, 3 with a 0.5-day cache, 24 for a 4-day cache and 48 for an 8-day cache.

Suddenly one of these tasks needs 5 hours instead of 4.
Upon its completion the BOINC client will adjust the estimated duration of all tasks from 4 to 5 hours.
The estimated duration of the 0.5-day queue will jump from 12 hours to 15 hours and the next request to fetch work will be delayed accordingly.
The estimated duration of the 4-day queue will jump from 4 days to 5 days and there will not be any new request to fetch work for almost one day (estimated durations will decrease slowly with each subsequent task ending again in 4 hours).
The estimated duration of the 8-day queue will jump from 8 days to 10 days and it will be potentially 2 days without asking for new work. With another consequence which is that all jobs will be running in high priority mode until the estimated duration for the whole queue has decreased enough.

Is it more clear now? Jean.

The queue size can be important - not technically, but rather for work management options.
I have done OK with snagging Beta work as evidenced by the recently acquired lump of gold to the left.
One of the mechanisms I have used is to run with a 0.5 day queue, and then when there is a Beta release I incrementally increase the queue.
After each increase the machine will request more work, and if the crunching gods smile upon you, more and more Beta units will be secured.
I once got 20+ WU's within about 2 hours on one dual core machine using this method.

So for me at least, the queue size has been crucial.

(Please be cautious with this as snagging 20 Beta's on one machine can cause severe face pain due to excessive grinning.)

Of course if those are a must have, just disable your NIC or unplug your network cable until all have completed or at least started. Then the server can't send the remote kill operation to those beautiful beta jobs

Another suggestion but not sure if starting all the jobs and then suspending them and starting the others would keep the jobs from being aborted?
I don't think I've ever been lucky enough to pull more than a couple betas at a time but I'd be willing to try this if the techs want to send me a dozen to experiment with

I can advise your test to prove this concept is unnecessary.

But watch what Sek is up to!

Hm, maybe WCG could start a new project: the Beta's for the Beta project...