Mike's comment showed a common belief, but it isn't actually right; as he said "as I understand it" in the part you didn't quote I'll try to clarify what does happen...

Every time the server receives a scheduler request it sifts through the list of tasks reported as on the host (if there are any) to deal with things like resending lost tasks and aborting unnecessary tasks. As you say, it doesn't know about checkpoints, just whether a task has started or not!

If a WU has been cancelled (bad batch?) an abort will be sent whether the task is running or not. (Not a common occurrence in general!)

For a viable WU, the task will only be aborted if it is not started. (That applies whatever the reason for potential abort might be,)

[Reference: Source file boinc/sched/handle_request.cpp at GitHub as current on 2025-03-14]

Cheers - Al.

P.S. The "if not checkpointed" idea has been around a long time, and I'll admit that I subscribed to it until a few years ago when someone pointed out that it [probably] wasn't the case; I then explored the source code to see for myself :-)

[Edited to add date of source check, rewrite the first sentence and fix a typo.]

Hi Al,
Many thanks for this explanation.
On a few occasions, I have noticed that an ARP1 task running on my machine has already validated. I contemplated aborting it, but was worried about that affecting the machine's "reliable" status.
In the current circumstances, do you think there is any real downside in aborting, were this situation to occur again?
Cheers,
Mark

If I find a WU running on my hosts and there has already been 2 valid WUs returned, I abort the running work. I would rather spend the cycles on another more useful target. I haven't noticed any degradation in reliable status as a result. There are 2 things that make that observation fuzzy though. One is the lack of accelerated and extreme work being distributed and, second, the general lack of work due to the various hosting site issues. Plus, I don't abort that many WUs by doing that so the server may not mark me unreliable. If I were to abort 7 or 8 at a time, that might be a different story.

Al

My recollection predates your search of the Source Code so I will update my memory.

Mike

So far as the 3 Ultras in generations 21 & 22 are concerned, the important thing is to get them moving again. The Extreme protocol should help them to catch up.

After them, There are 8 extremes in generations 104 - 110, followed by 12 in generations 115 - 124,

None of those generations contain more than 2 units.

We then have 295 extremes in generations 125 - 131.

All of them appear to be stuck.

There are 451 accelerated in generations 132 - 136, of which only 3 seem to be moving.

Also, some of the normals appear to be stuck.

Please bear in mind that the final generation would be 182.

Mike