I've never seen a high priority task that didn't complete within the deadline on it's own. What settings are you running?
OS type and version and BOINC client version might be useful as well.

Another thing which occasionally cause this to happen is wide variability in the completion of the tasks which are queued. I have experienced this with the Childhood Cancer project on a P4. Some task which is an outlier to what BOINC expects will trigger the high priority setting for the remainder of the tasks. Most of the tasks were taking 12 hours or less, but one took 39+ hours and thus threw off the rest of the expected completion times for the rest of queue. BOINC really does learn very well how to complete tasks in a timely manner, but it can not predict when something will occur outside its normal parameters.

Cheers

SekerRob - Good explanation.

Cheers

Hi,

Starts to look like your crunching schedule is part of the cause. Tell us your "Connect about every xx days" and "Additional Buffer / Cache" settings on the Local Preferences, Network tab.

Underlying problem is that during the work week your client is probably returning results within 48 hours. This causes your client to be deemed a reliable host [tasks have to be valid of course]. Then on Monday, when you have such short deadline tasks, you are 2.75 days later (9 to 5 workdays). At that time any short deadline task would be run in high priority as the client does not understand concepts of weekend, just assumes that if the client only was on for a x-fraction of the time, it has to expect that it will be the same in the future i.e. goes in overdrive.

The following tip only works on 6.10.58 and earlier. Set "switch between applications" to 6000 minutes. This way your client will think that any short deadline job will not be completed in time. If received, they will be executed immediately rather than waiting for it's turn in FIDO order Any of the 7 or 10 day deadline tasks will be made to wait. Also if not already, set the activity menu to "Run based on preferences". This forces *all* scheduling prefs to be followed.

All of the above is speculation and assumption. The connect interval and cache settings will round out the information upon which a more precise advise can be given how to end the problem or at least reduce it to incidental. Still, BOINC is supposed to learn and fetch work based on the running fraction as maintained in the <on_frac> and <active_frac> values. These are mine and considering this is 24/7 since Jan 4, the on_frac is puzzling.

<time_stats>
<on_frac>0.816470</on_frac>
<connected_frac>0.594517</connected_frac>
<active_frac>0.999499</active_frac>
<gpu_active_frac>0.939058</gpu_active_frac>

As you see, supposedly this client is 81.6% of the time on and of that time, it's 99.95% active [crunching]. The connect value is right as networking is not allowed during the night hours, till 10:30 AM...bout 60% on. Your values can be found in the client_state.xml located in the BOINC data dir [do not mess with this file, just view it briefly]. Those values will add to getting the picture.

--//--

Sorry, I'm in a rush this moment, but your BOINC on for 30.53% of the time and off that time is allowed to operate 88.3%, so kind of runs 6 hours per day per those figures. The equation is that if a 20 hour job only is allowed to run 6 hours a day, BOINC figures it needs 3+ days to complete such a task.

Short deadline does not necessarily mean the tasks will be processed per deadline. Just let it run and on Friday noon set work fetch to No in the projects tab, so least work is cached and sits idle over the weekend. Then on Monday set workfetch on.

--//--