Sure as heck, if you run your cache close or over the repair deadlines and one or the other task runs longer causing to inflated the whole cache, there's panic. As the FAQ states, if you micromanage and run larger cache you'll be needing coffee (nothing at all to do with personal prefs, but I like good coffee anyhow ;-). Those that don't and set a 'smart' cache level never have to and can forget running BOINC... it's design purpose.

Dynamic deadline... not new... WCG has been doing that for years for the devices that *need* extra time. If 7 or 10 days is a problem, then size down the cache... hear the mantra?

For wanting to rush Beta tasks, to have a *remote* chance of getting another when completed / returned in the 1:1 per core rule, this was understood, else the WCG system really could not care less whether a repair/beta comes back today or tomorrow, long as it comes back before the deadline.

As for restof's observation, we've gone through that long before in a ''hair split discussion''. Who cares whether the first or last of the same time due is processed. To BOINC the order at which tasks were entered into the client_state.xml (random when a batch assigns e.g. 15 in one call), is how it processes them, so it will when there's panic try the last LIFO not FIFO for a while to find out how they run (which may not be the order you see in the task view).

Since the scheduling is constantly developed even from point release to point release and the BOINC 7 client (numbered 6.13 in development) is again going to do it *very* differently it is kind of trying to understand how it works, but not knowing what levers are being operated. Some asked for a trick to *automate* the short deadline rush and they've got it. Those who want to do the scheduling themselves... they can do the scheduling themselves, but should not expect lucency trying to argue with a computer.... you'll always loose.

Net, run a cache that is constantly over 2 days, even with the repairs being rushed and eventually the client will be taken off the quick return, reliability list... no more repairs... all production work at least with a 7 day deadline (HCC having the current shortest). For Beta it does not matter at all. The purpose of Beta is to test all devices, good or not so reliable, to find the bugs. :D

--//--

P.S. andzgrid, have fun doing your suspend/start tricks... that's addictive crunching if done more than incidental... maybe cut down on the coffee ;O)

Indeed haywire, so like you, found lower values good too... depends for instance on the sum of the cache and the switch time, so if there is a 3 day cache and a 4 day deadline task is in, a 1500 minutes value will do the same, skipping up the WUs in question... but as stated in the FAQ, not all clients behave same, so trial and error is needed to find the client sweetpoint.

Will add this good observation to the write-up... thanks for reminding

--//--