The early departures with 29 are by design as in "we know they signal to be of no further use". The way they come and go off stage does get the razzie prize if such a prize were to be given in distributed computing.

Meantime the 3 I have left after the first 2 with 29 are now on 60 and 70%... expecting them to finish proper.

ts05_a193_ps0000 is a fine example for three errors 29 at totally different locations. An what is more - at least my WU has the error only after running more than 30% uninterrupted. If it is restarted from the last backup immediately before the last error position, it continues for another 30%, i.e. the error is not reproducible this way at the same location, i.e. the task needs always more than 30% unibnterrupted running to discover that it is of no further use... ;-)
Of course this does not apply to all WUs which error immediately after starting.

Yes, you are right. After a task had an error, all checkpoints are lost.
But I had the same situation before during the beta test (messages can be found within the beta test thread). So I stop boinc from time to time to make a backup of the boinc data directory if long running WUs are active (in fact I'm used to do it since I run climate prediction WUs which take some weeks to completion). Network access is disabled all the time to prevent boinc from reporting failures.
So when the error occurred I stopped boinc again and copied all files for that WU from the backup (slot directory including checkpoints, client state parts, _2 file). Then I restarted boinc and the restored WU was available again. Of course there is some loss because I do not know the time of the next error for sure. But I do not loose the WU.
BTW WU ts05_a193_ps0000_1 had error 29 again at 94% completion after running 32% uninterrupted - exactly the same percentage as with the first error. So I'm pretty sure that it depends on the used resources rather than finding out to be of no further use. For the night I leave it suspended and will complete it tomorrow.

Good night!
Matthias

It seems like these monster tasks for DDDT-2 were poorly designed, particularly in the case where ts05_a193_ps0000_1 and ts05_b159_ps0000_1 appear to be running successfully by stopping and starting BOINC. I think of BOINC as a user interface to see what is being executed, and not the actual execution of the tasks which are being continuously executed in the background with BOINC active or not. Wouldn't suspending and resuming a task with BOINC have the same results? The checkpoint of the task is to provide a point at which to restart should your computer go down or needs to be rebooted for some other reason such as a Windows update for security reasons.

Sek, I restarted the tasks at 08:38:25 MESZ (computer was restarted as well) and now after 52 min and +1.8% they both have 213MB RAM and 805MB VM.
Do you know whether the memory allocation is step by step or all at once?
Concerning the restart - I wait until the next checkpoint is reached and suspend the task immediately afterwards. If all tasks are suspended I stop boinc and make the backup.

Matthias