yes, you are right.

Those are permitted values. As said, BOINC connects to fetch work or send results irrespective if it senses there is a connection.

The 0.0000 cache could work out that the client only fetches work when the job is finished. That could cause some idle time. Not tried it, so not sure.

Ok guys,

So fool around with the timimgs as I have done and you will find that just before the WU that is running approaches completion, it will request a new WU into the buffer. (just a minute or two before the current WU completes).

Changing the timimgs up as your posts suggests, bring in the wu a lot sooner, and don't give as good a representation of turnaround time; which was the op's question I think.

I have mine set this way so it has the absolute shortest turnaround I can achieve.... I see it as senseless to have the work buffer queued to 10 days out.... and have things just sitting there holding others up before processing can begin.

I get WU{n}, Process it; get WU{n+1} just before WU{n} completes. So WU{n+1} sits awaiting selection for execution on my machine for a very short time.

Yeah, Yeah, Yeah, there are pros and cons to the whole bloody thing. Personally, when the WCG queue becomes empty and thee's nothing to process... then that's a good thing... but on the otherhand, there are likely others out there that still have up to hundreds of WU's in their queues to still process and return as I sit idle.