Ps, what nowadays ssd fitted node takes 21 hours and not checkpoint for ugm? There could be something wrong with your host, considering the project mean is 3.5 hours runtime per result. Good you opted out as wasting time on a project a device cannot handle is not a good thing.

What kind of computer are we talking about that it takes more than 21 hrs to complete an ugm task?
I mean I have two amd 5350 kabini devices running at 2 GHz. These are cheap low power cpu. But even with those slow cpu runtime for ugm is between 5 and 8 hrs per task.
I bet my android devices wouldn't be much slower if there would be ugm for android.
So how could your devices need more than 21 hrs?

Come on children, put the pea-shooters away ...

First off, UGM does checkpoint, very regularly, every 10 minutes. I've never set WTD to longer than 10 minutes so I don't know for sure that it respects that -- mine's currently set to 3 minutes -- but I have no reason to think that it doesn't. And, as has already been said, the issue with mini-writes every few seconds is being addressed and a fix is in alpha test right now.

What we do know about UGM is that it uses a more modern instruction that's not available on very old computers, so you might be hitting that. But I have a P4 that runs these OK and even the largest units have finished in around 20 hours CPU.

I wonder if you are confusing wall-time with CPU time and your processor was "stuck"? What happened after the re-boot, exactly?

If you'd like the community to help you please post the start-up lines from the BOINC message log along with anything else that might help. If this unit is long gone, then I suggest you wait for the new code and then try this project again to re-evaluate its behaviour.

People will be more inclined to help you if you are just a little more polite. Don't vent your spleen until you have some proper ammunition, backed up with data, and not just supposition.

The 'checkpoint writing' properly follows the 'write to disk at most' setting, default 60 seconds. Ok back then with single and dual cores, not good when running 4-8 threads and more. Then it becomes one being written every 8-15 seconds. This is why having this setting at 300-600 seconds is better, less writes, myself having wtdam at 1000 seconds. Not worried about incidental losses on boot or client restart.

Since the checkpoint writes are like clockwork at system start/restart, this creates a bottleneck when 4-8 or more write their checkpoint simultaneous until the concurrent ugm tasks over time desync their writes, which is latest when they finish and the next start.

Why the op poster had no checkpointing, pass, maybe a device that has no sse2, p3 cpu level, then computing would fail for ugm. It's one of those 'very rare' reports, hardly reproducible in test labs. Knowing the exact computing environment would help for starters. But if this single fail on over 6.3 million completed results could kick an investigation is not my expectation.

Btw, there is in some recent versions of boinctasks a bug in the checkpoint counter. Now running 1.67 which appears to increment them properly.