There's an except: You with late reporting have caused the 3rd computer to waste time so you can help by reducing your cache/additional buffer size.

The servers immediately set a signal ready for any client with a redundant result not yet returned, but if the client has started such a task BEFORE contacting the server to receive the signal, the task it is let to finish, so all time is credited, in full.

Hmm, I remember this functionality being discussed, but AFAIK it wasn't added, atleast not at this time. That is included, is:

1; All unstarted work is aborted then passing the deadline.
2; A new function was added to the api, so instead of continuing past the deadline, the application can choose to end early, and send whatever it's already done back to server.

#1 works automatically for all projects, while #2 must be added to each application if project wants to use it.

No worries and for the cancelling, point 2 of Ingleside's augmentation could create that possibility for WCG... but whether it pleases everyone is a different matter v.v. some who are motivated to squeeze the last second out of 'short supply' work. I though think that WCG in the first instance strives for highest efficiency in the most 'set and forget' possible environment, thus credit for time is due.

happy crunching.

It's a good point, those total efficiency driven being OK with mid-trip cancellation, not suiting everyone. For everything there's a solution though... an option in the settings that says yes/no to permit auto-abort for applications that have the build in functionality.

The task abort code works as follows:

1) If a task is no longer needed (i.e. validation on the workunit has completed and the canonical result has been identified), then an abort if not started message is added to the scheduler request reply the next time the client communicates with the server. This will cause the task to be aborted if it has not yet been started.

2) If the task cannot be used (the workunit is canceled, or if it is so late the workunit has been deleted, etc), then a task abort message is added to the scheduler request reply the next time the client communicates with the server. This will cause the task to be aborted no matter what.

There was the intention to add a preference to BOINC at some point that would allow a user to change how #1 above is handled so that it will either behave like a 'abort if not started' or always 'abort'. I do not believe that this has yet been added.

The reason that there are two behaviors here is that 'credit' is reward given to members for their contribution. I do not want to argue about how important this is in this thread. Suffice it to say that if you are contributor A and you have a task that goes past its deadline. Contributor B has a computer that is always on and has a short queue and is assigned the additional replica that is sent out for the workunit. Contributor A returns the result 6 hours after the deadline and the workunit validates and the canonical result is archived. Contributor B's computer has been working on the result for 6 hours contacts the server to get more work and finds out that its result is no longer required. If the result is aborted and returned as error (aborts are considered errors), then Contributor B gets no credit for the work they did. This is unfair and so the rules above were implemented.

Could something else be implemented? Yes. However, the situation above is not common. Most results that miss their deadline are not ever returned (or are returned long after workunit has been deleted from the system which means that it is over 1 week late). It is much more useful to spend the time working on doing what can be done to ensure that computers can return their results on time. We are working towards providing workunits of different sizes that will be sent to computers that are able to complete them within the allocated time frame. This will do much to avoid the problem in the first place.