You created the situation. The default is about 0.3 days. The client projects completion time based on last finished work. If you have 10 days buffer [with a 10 day deadline, but HCC also having 7 days] and these tasks are estimated at 6 hours each, then the latest one finishing in 8 hours, the formula is broadly 10 days * 8 / 6 = 13.3 days for the work that was buffered after the last completed task. This means your device has at least 3.3 days too much to complete withing deadline. Now BOINC is not completely stupid [but lots smarter than most think it is]. What it does in that situation is testing the latest arrivals to see how long they run... could be 5 hours, so it runs a bunch to find out, but eventually when it determines things dont improve it is switching to the earliest deadline first order.

Keep in mind that when you run a 10 day cache on a regular basis, work processed today is already > than 9 days old, so you basically create a near permanent panic state in the scheduler [which uses a safety margin on top before calling emergency].

Why 5 days I don't know. The highest I ever run is 2 days, briefly **, when knowing that either server or ISP is going to be out for longer. But strictly, WCG outages are rare, planned and hardly longer that 6-8 hours, ergo, if you run with a 1 day cache with a reliable ISP that's more than enough.

Of course, some set a backup project that *always* has work [take your pick]. That project can be configured with zero resource share/project weight. Only when the client runs dry, will it go and fetch some work there until WCG is back. Soon as WCG is back, will those backup project tasks be parked [behavior varies per client version].

--//--

edit: ** There is the rare work exception... then load up and set cache immediately back to low and do what you've committed to doing... not abort, because that loads the problem onto other crunchers.

Fixed

Thanks for the replies. I've learned the hard way 10 day queue is bad.