My understanding is that if BOINC determines that a workunit might miss its deadline, it will automatically set that workunit to "high priority" and run it more or less exclusively, including pausing other workunits, in order to make the best effort to return on time. If the deadline is still missed, a new copy is sent out to someone else, but your workunit is not automatically abandoned. If you return the workunit before the extra copy returns, you will receive credit. If the extra copy returns first, your copy is marked "Too Late" and receives no credit.

All in all, it's better not to intervene as BOINC will try to make the best effort automatically, including making adjustments to workunit/process priorities, both in the BOINC scheduler and on your actual machine. I've had this happen before, and haven't missed a deadline yet.

See also: https://secure.worldcommunitygrid.org/forums/wcg/viewthread?thread=17160

Some extra info on the work scheduler (with a mess 'o links) from the Unofficial BOINC Wiki: http://www.boinc-wiki.info/Work_Scheduler

Apparently, the exact manner in which late workunits are handled can also vary from project to project (so also, in the case of an umbrella project like WCG, subproject to subproject? See World Community Grid forum link above).

Disclaimer: All of the above is subject to change depending on someone else knowing better than me.

All this being said it leads to the question is if it would be wise to just adjust your cache levels downward by a day and see if that puts an end to your being late, or almost late.

Thanks for your input gents and some good links.

The reason I find myself needing this information is that some of the guys on the team need every last minute of runtime to get their water badges.

Some have big caches downloaded all at once, so, many pages of work all due to finish in a 3 hour window some days hence. quick calculations suggest that a couple of pages at least will be late.

The cache size at the time of download was 7 days but due to the difference between cpu time and real time running these ( and other work carried out on rig) The amount downloaded was a little high.

I guess that it is best to let it run because those wu's started will most definitely complete before any re-issued task provided that switch between applications every x minutes is greater than 2 * task duration.

Unfortunately, the congestion this 1 repair assignment per host would cause on the feeder side [the repair jobs having first priority on distribution [to reliable devices], and will hold up any backfilling of regular due date jobs, meaning that not 100% reliable devices would not get work until all the repair work is out the queue]. That the ~80 short deadline tasks were suddenly gone could be for several reasons, such as:

A) because the late reporters of completed work still reported and yours got a server abort instruction, being redundant
B) the client decided that it was over-commit [less likely, and actually cant remember seeing this ever happen to my hosts].
C) bug
D) don't know (Ingleside could).

The message log would print the reason.

As yet, I've found that being cached under 2 days has not left the device dry once, even through the various troubles we had in past months. With the latest test client and 1.5 days cache [meaning if long jobs come along, the cache inflates to over 2 days or more] this gives me frequent prioritization of repairs, but not too much. Any short deadline job that approaches 2.5 days due gets put ahead, but that's as they complete i.e. not all at the same time, well fitting in the 7GB RAM allowed to BOINC.

Connect 1 day interval actually amplifies the panic state [though uploading of result files is continuous if an internet connection is set active]. Suppose a task is 1.5 days due and there's 2 days buffer ahead in FIFO order. The client also considers that it wont reconnect until another 24 hours have passed to clear the Ready to Report and fetch new work [6.10 client], so it reckons that the 1.5 days due will only make it if put ahead. Earliest Deadline First kicks in.

The scheduler is not perfect, it is still being tweaked, and reality is, it tries to cater for an infinite number of project combinations and scenarios. Even with the said latest test client [7.0.36], I see head-scratchers, and that with a 1.5 day buffer setting. I just let it ride. 3-4 days buffer setting and up... that's though a guaranteed panic state condition set up for a reliable device [really, if running continuous 3 days or up, there should not be any repairs coming as the criteria is, to regular return under 2 days]. Anyway, there's a web-option in the unscheduled ToDo list to disable repairs in the web device profile, which means that apart from Beta, all tasks have at least a 7 day deadline. Can't see how any task on a 3 day cache could miss deadline on that.

Loose bits of info.

If a job is put in per-empted and there is enough Swap file space, I'd thought that the paused tasks used RAM memory segment is moved to Swap file. For Windows the default of Swap is about 1.5 times RAM, space galore. At 64 times 35MB (that what HCC is taking in peak on my W7 ATM), that would be 2.2 Gig. With HFCC, taking peak at 165MB, that's 11GB, still within the 16GB you''ve got on that crunching monster.

Setting to check: Is RAM permission during work/idle set to 100% or close to that?

BTW, Murphy was listening in... now got 6 HCC running in HP on the octo, due in 2:17 days, with 1.5 cache MinBuffer (which is aka "connect every..."). No disk trashing/swapping... all operation within the 7GB permitted including the 6 that were preempted