It is my understanding that as long as a sufficient caches is set for the capacity of one's rig, all tasks should complete within its deadline.
I don't micromanage Boinc & only manage when switching to a different project.
As I am solely crunching WCG I either change profile or project to reach specific target.
I have just had 20 tasks error & 11 tasks time out.
The tasks that error do not show up in the error tab but the aborted tab - I did not abort them so assuming that they were server aborted, even though they do not show up in that tab. Looking at them, I can see that they would have definitely timed out.
My cache is set for 6 days with 0.01 additional so can't understand as how this occurred.
Ideas anyone?

Given the short deadlines that WCG normally uses it would be worth trying dropping your cache to something like or 3 days plus 0.01
I had a bunch of WCG tasks that were server aborted some time back - I just happened to be looking at the screen when it happened, so I guess that if they find "something wrong" with a block of tasks, or the application they dump them and possibly send them out later on when they've solved the problem.

Thanks Rob, reduced it to 4. Not that it will matter for some time as now getting 1 for 1 due to the number of failed tasks.
Hopefully it shouldn't take too long. :-)
Must have been a good boy. :-)
07/08/2020 21:43:25 | World Community Grid | Sending scheduler request: To fetch work.
07/08/2020 21:43:25 | World Community Grid | Requesting new tasks for CPU
07/08/2020 21:43:28 | World Community Grid | Scheduler request completed: got 145 new tasks
Much better as got some more then this:
07/08/2020 22:27:53 | World Community Grid | Reporting 1 completed tasks
07/08/2020 22:27:53 | World Community Grid | Not requesting tasks: don't need (CPU: job cache full; NVIDIA GPU: )
07/08/2020 22:27:56 | World Community Grid | Scheduler request completed

While you are on the enforced diet you will be able to make sure that everything else is OK - I hope that everything is OK.

Diet? I don't think so. Last time this happened was earlier this year with TN-Grid. Thought then that there would be many time-outs. I was wrong as only had a couple.
Getting up a short time ago (too hot to get a really good sleep), checked on BM, didn't like what I saw so checked event log,
Before that 145 batch, it D/L'ed 134 followed by another 38 after the 145. (got it set on NNT now)

Had they all been 3 hr xx min like the last bunch, then maybe but they are all 5hr 16min. Now WCG has some slack in both Linux & Win. On my rigs it ranges between 15 - 30min between cpu time & real time.
So for argument's sake, lets make that 16min, so in 24 hrs should complete 4.8 tasks per core.
Times that x8 = 38.4.
So for just 4 days that should be 153.6 tasks
If deadline of 7 days is taken into account that is 268.8
Oops...
Will keep an eye on them.
Secondly, with the amount of failed tasks returned, shouldn't Boinc have backed off & stuck to what it 1st did - 1 out 1 in regardless of what setting the cache was/is?
Edit: Checking on the device stats on WCG the 8 core has averaged 42 tasks per day this month.

Unless that machine is away from the internet for extended periods, you really don't need a multi-day work cache. All my machines are on less than a day, and most of them are on 6 hours.

Okay have set it to 1 day & I'll see what happens when this batch completes. Only had it set on 6 due to crunching Seti too long & didn't want to keep hitting the servers too often. Is there any need to have any additional then?

Well, it's kind not to keep hitting anybody else's servers, too - especially when they're taking a mighty hitting from the influx of SETI exiles.

I actually set mine to 0.25 (that's the six hours) plus 0.05 (about an hour). If you finish any work, you're going to hit the server anyway within the hour, to report it. So you might as well grab a top-up while you're at it - saves making a double hit.

I actually set mine to 0.25 (that's the six hours) plus 0.05 (about an hour). If you finish any work, you're going to hit the server anyway within the hour, to report it. So you might as well grab a top-up while you're at it - saves making a double hit.

Unless I'm completely misunderstanding the role that a cache plays, I find that such a small cache produces problems with some projects, for example, WCG African Rainfall. That project takes between 32 to 42 hours per task on my dual cores, so with such a small cache, no work would be received.

Doesn't affect me. I'm just finishing some CPDN tasks, well into their 11th day of running. They were downloaded immediately I released the 'No New Tasks' for the project (it was a special request run - not my usual fare).

I think you're confusing runtimes with deadlines. BOINC won't download a task if it thinks you can't complete it before deadline, but that's not the same thing as the cache setting.

Possibly. With an 0.25 & 0.05 cache, how many tasks will be downloaded per core on an initial run?

Turn on <sched_op_debug> logging, and it'll you the size of the work request in seconds.

The very first request (when you first join) is always 1 second.

If you are entirely empty, the first 'real' request will be 25,920 seconds per device (core or GPU). How many tasks that turns into depends on the running average estimate of the speed of your device. If you have some work already, the request will be reduced accordingly.

It's turned on so I'll see what happens later this evening.
As for the 317 tasks it downloaded, it looks it is not as bad as I perceived. It has 29 tasks remaining with 8 crunching.
4 will complete within deadline the other 4 will over run by 2 to 24 minutes so more than likely I'll be credited with them.
The remaining 21 will timeout by their deadline of 21:45 tonight.
Looking at my results status I am surprised by the rigs stating "no reply". Mostly all 64 bit with all flavours of O/S.
I'm left wondering - Is that an issue with either WCG's or Boinc's scheduler?

Surprised as the 4 I thought would over run, completed within 2 minutes of deadline. Actually saw 13 get aborted.
Changed cache to 1 day, 0 additional & resumed download & only got 42 tasks. Good enough as this rig averages 45-55 a day
Just cannot understand why this issue as while crunching MCM to get to Ruby, no problems whatsoever. Changing back to MCM for Emerald after reaching Ruby on MIPS...

As for this, pretty high numbers:
14/08/2020 22:14:25 | World Community Grid | [sched_op] CPU work request: 224340.11 seconds; 0.00 devices