Well - I'd disagree.

If you had a VERY large cache (I use 10 days) then a task sent 20100418 would be unlikely to be started 20100419.

Is the 'server abort' facility active on WCG - and if so, does it work? Was an abort sent by WCG when the 'too late' unit was received? I've seen other projects abort tasks. Is it used? Is it working? Does it work on a started task?

Or, for future consideration, should BOINC allow retrieval of a progress report so the deadline for a 'late' unit could be extended if progress is being made?

Perhaps the abort message wasn't sent because of the server problem at WCG to which knreed refers in the 'network outage' sticky - sadly, there's no reference to the actual times of the outage.

I'd suggest regular forum-readers are well aware that a few particularly chewy units can push others over the deadline, and monitor progress closely.

Could a large cache be the solution to Novosel's "shut down pc options" thread in the BOINC Agent Support forum? 5-6 days should ensure that there's always work available, and that should also be short enough to ensure that the work is done before the deadline, even when unusually long runtimes are encountered.

A small cache might suit machines that are permanently-connected under normal circumstances, but we've had outages that have lasted days (as have other BOINC projects) and when that happens (a long outage either end) a small cache is not as good as a large one. All sorts of problems can occur at either end - fire, flood, snow, equipment failure. Even some clown digging up a fibre-optic cable...

Overall, I'd say a nice chunky cache is preferable to a small one.

If that is the case, then why do we allow people to cache that much in the first place? Why not have a 10 day deadline, but allow, for instance, a max of 7 days cache?

It's the limitation of the BOINC client which happens to coincide with the WCG general deadline... which is one set to allow most all part time crunchers to complete a task comfortably. Not sure if WCG could even limit that cached work provision. It will give a max of 15 per call, 80 per core per day as a generalized rule to cater for even the most powerful devices.

I cache 3 days work.
That should cover 99.999999% of the outages that WCG could possibly have and also keep the amount of cached work "under control" in case I need to pull a machine down for a day for repair or upgrade..

fredski,

not seeking to blame, just trying to learn and where possible make that 180 degrees so we can cut that average return time further down, within the system as it currently works.

As for the business trips etc, that falls in that first broad line of the opening post
... unless there was a technical glitch for not starting the job in time:

Those who see this most frequently are those in the < 2 days return group... these devices do the repair and make-up work and are often called to task in acting as verifiers for ínconclusives... no problem, but being the 3rd copy for a No Reply that still comes in... let's work to minimize those with a little help of each other.