I see some of the ARP tasks have a half week deadline instead of 1 week - why is this? These are often returned a little late by me, due to Boinc being absolutely useless with scheduling. It enters panic mode far too late. I have a 0+3 hour buffer, so there isn't usually a queue, but I run a few projects with multicore tasks, and Boinc just gets all confused, the poor little thing. It sees tasks that can fill all the cores and does them, leaving the ARP tasks sat there doing nothing until the last minute, because there aren't enough of them to fill all the cores. Then it crams them in at the same time as the multicore tasks and wonders why they take longer than expected!

So my question is, if I return one a little late, is it still useful? Or will it have been resent?

I've heard of the following happening: In Primegrid if you're sending trickleups, they give you extra time. In some projects the task is immediately sent to someone else when you miss the deadline, even though you're at 90%, then when you send it in, you get the credits, the project gets the results it needs, but the other guy is wasting his time, and if he's started it, the project doesn't cancel the task!

That's what I thought would happen. What should happen is it should get server aborted even if they've started it. They're wasting their time doing what's already been completed by someone else, and could be working on another task. If you feel this might upset them by cancelling it halfway, then by all means give them credit for their attempted work, but there's no point in them continuing to run an already completed task. It is possible to do this, the Boinc server does have a command to cancel work in progress.

The "Too Late" occurs when the re-send validates the original before "No Reply" replies whether started or not.

The problem here is that there may be times when it is probably more equitable to let a task finish anyway - if the task is (say) 90% complete should it still be cancelled???

I don't think the server normally knows the fine details of task progress - it is probably "Not started" -> "Started" -> "Finished", in which case how can it assess a running job? If a job is aborted whilst running, is there any guarantee that there's an accurate estimate of work done before cancellation? (In re badges and credit, for those it concerns...) Projects like CPDN can do partial credit for tasks that fail to complete because they base credit on trickles rather than on total work - I don't know whether such an approach would be practical for WCG...

(If I'm wrong about aborted task status, would someone who is familiar with the live code please explain what the actual position is!)

Bear in mind that quite a few contributors focus on one or two projects at a time, and if their jobs were being prematurely terminated I suspect they'd be extremely unhappy! There are also lots of folks here who are enthusiastic badge-collectors, and if they kept having partially completed tasks cancelled without contributing to their time used, more "unhappiness" would be seen. Too much of that could lead to contributors giving up!


I think you've left "in my opinion" off the above! Whilst I'm inclined to agree about wasted time, see my previous points regarding potential user reaction! Perhaps the answer might be to have a configuration option along the lines of "Should we abort running tasks whose results are no longer needed?" with a note regarding whether credit will be awarded or not.

As for waste, for some ARP1 project users the biggest waste would already have happened if the job is abandoned (whether started or not) because of the enormous download it requires...


The "Abort tasks whether started or not" facility is primarily intended for situations where there is something wrong with the tasks or it is known there is something wrong with a particular user's client.

I would love to know what sort of discussions take place at various BOINC project places regarding what to do about late-running tasks! I suspect there's no "one size fits all" solution, and "let it finish" is the easiest implementation (albeit sub-optimal in several ways!)

Cheers - Al.

Of course, otherwise the processing that user is doing, using his electricity, is going nowhere.

I shake my head in shame at those who do it for credits.

Good idea, as that would both solve the problem of wasted CPU cycles, and nobody in their right mind would choose "no, let me continue working on something that will be thrown in the bin".

So no further harm done cancelling it.

How is this any different? The tasks in question are of no use to the scientists, continuing to run them is moronic.

More likely nobody considers it much at all and things get left on defaults until it causes them a noticeable problem.