Of course. Projects can choose to accept late work, and even issue credits retroactively.

Without knowing the policy in advance, we must assume a deadline is set for a reason, and the project knows what it's doing. Therefore, we must assume any work after a deadline that is just a waste of time and energy. And in this case, it is. Once that deadline passed, another copy was sent to another cruncher. And only one of the two is needed back.



See my earlier comment. Any deadline 24 hours or less has the same result with regard to scheduling and prioritization. Had it been set to (say) 23 hours, the work would still have been done in exactly the same time, but without the abort problem that you are trying to avoid. In other words, the project is causing the abort problem, not the crunchers.

The only hard prediction seen is that the 2 WU in the quorum linked in the OP were under 6 hours. The flops packed in the header of a work unit are just estimates. Very often my desktop crunches those WU's in 50/60% of the original predicted time.

Hope one day, there will be an 'Info' View in BOINC with the key parameters. BOINCview e.g. already lists out all attached project DCF's, my key reference to judge if something is awry on the machine.

As has been mentioned the completion time is only an estimate, I had 10hrs est for a wu but it completed in 6, some others for the same wu took 8 hrs plus but all valid results received credit.

Even so, it is still accurate. This is straight from John McLeod VII, the guy who rewrote the scheduler, from the BOINC alpha testing alias (of which I am a member):

"Computation deadline = report deadline - ( connect every X + switch projects every X, + 1 day)"

So let's do the math with some best case values:

Computation deadline = 6 hour report deadline - (connect every .01 days + switch projects every 0 (only this project) + 24 hours)

Computation deadline = 6 - (.01+0+24)

Computation deadline = -18.01

Do you see now? The *best case* would have to be a report deadline of 24.01 hours or greater, to prevent EDF.

In summary, there is no difference between a report deadline of 6 hours, or 23 hours. Both will cause EDF immediately. Both will for the the result to the front of the queue.

Using 6 hours is causing some people to do the natural thing, by aborting results. Nobody wants this, but it is clearly happening.

Using 23 hours (or anything reasonably larger, but less than 24.01) will still cause the goal of EDF, but not cause people to abort results.

So why stick with 6 hours? It makes no sense, and it tells me that the project does not understand the scheduling logic. So here is the feedback (which is the whole point in running a BETA): The project needs to increase the report deadline.

I'll take JM7's word over yours, thanks. He wrote it, and he knows it better than anyone.

In any case, leave it like it is if you want. It's your project. But then don't complain when people abort tasks. They're doing the logical thing.

Also, you shouldn't running BETA tasks if you don't want feedback.