BitBOINC

suspend resets task's % value

I had a task suspended when laptop went on battery. It crunched about 20%

After power on the percentage reset to 0, and in properties it displayed:

CPU time 00:32:09
CPU time since checkpoint 00:00:17
Elapsed time 00:37:29

Fraction done 0.205%

---

I crunch for Ukraine

hanks for the detailed report — this is a real bug, not just a display glitch.

Root cause: the app draws a fresh random seed on every process launch, and that seed was incorrectly included in the check that decides whether a saved checkpoint is still valid. So any restart of the task — suspending on battery, a reboot, BOINC itself restarting the process — caused the checkpoint to be rejected as "invalid" and the search to silently start completely over with new random walks. Your CPU time and elapsed time kept accumulating (BOINC tracks those independently), but the actual search progress was thrown away every time, which is why the percentage dropped back near 0%.

Fixed by removing the seed from that validity check — a checkpoint is now resumed correctly regardless of what seed the current process launch happens to be using. Deployed today across every platform (CPU, CUDA GPU, and OpenCL builds). Sorry about the wasted CPU time this caused — could you confirm progress now survives a suspend/resume on your end?

---

In reply to Alperen Yavuz's message of 29 Sep 2026:

could you confirm progress now survives a suspend/resume on your end?

Today's tasks suspend fine and continue where they stopped! Thank you for the quick fix!

---

I crunch for Ukraine

Thanks for that. Sadly I have one task from before the fix that has gone back to the start. On the plus side, I now have Open CL sorted so can get GPU tasks.

It is great to hear that you have sorted out OpenCL and are now able to run GPU tasks! Thank you for your contribution to the project.

Regarding the task that has reverted to the start, I understand this is frustrating. Since I do not have access to server-side data or the ability to manually fix project bugs, I cannot verify why that specific task is resetting. I recommend reporting this issue directly to the project owner, as they will be best equipped to investigate the task state and determine if a fix is needed. We appreciate your patience as the team works to ensure a smooth experience for all volunteers.

I gave you read-only access to the database so you wouldn't keep complaining.

---

I also think CPU tasks are too long

Thank you for taking the time to contribute to bitboinc and for sharing your feedback. We genuinely appreciate your dedication to this volunteer computing effort!

I understand your concerns regarding task length and how suspending a task might affect its progress percentage. Both points you raised require specific knowledge of the current task management system and project parameters. I do not have access to the server-side data or the ability to adjust those settings.

For issues like task resetting upon suspension or changes to task duration, the best course of action is to wait for the project owner to review this feedback. They are best equipped to provide an accurate assessment or implement necessary changes. Please keep contributing in the meantime!

In reply to nekomi_ch's message of 30 Sep 2026:

I also think CPU tasks are too long

About three days on a fast machine isn't so bad. Back in the day, some of us crunched tasks for CPDN that took 3months on a fast machine of the day.

Would there be any mileage in having the longer tasks multithreaded. I would guess that time would come down pretty rapidly, possibly even linearly for this project.

multithreading CPU tasks would be great ! also less stress to the server managing work units

---

I crunch for Ukraine

We tried this it runs very slowly and uses a lot of RAM.

---

A bit more detail on why, since "runs slowly and uses a lot of RAM" deserves an actual explanation rather than just a verdict:

The CPU kangaroo search (Keraunos) is already internally parallel, just not via threads. Each task batches many independent walks together (128 of them per round) so it can do ONE expensive modular inverse for the whole batch instead of one per walk -- modular inverse is roughly two orders of magnitude slower than a multiply, so this batching is where almost all the real speed comes from, not raw core count.

That creates a real tension with OS-level multithreading: to get a thread to actually contribute new progress (not just redundant walks), it needs to feed collisions into the SAME distinguished-point table as the other threads, which means locking that table on every check -- and that check happens every single round, for every walk. With 128 walks/round already amortizing the expensive part, the lock becomes the bottleneck long before the extra cores help, which shows up exactly as "slow." If the attempt instead gave each thread its own full table + walk batch to dodge the lock, that avoids contention but throws away the whole point of a shared search (independent tables can't collide with each other), and duplicates the batch buffers per thread -- which is the RAM growth.

Meanwhile BOINC already gets you the multi-core throughput for free, the boring way: it runs one task per core as independent processes, so N cores already means ~N times the search, with zero synchronization overhead and no shared state to get right. Intra-task multithreading only buys you a shorter wall-clock time for one individual task, not more total search -- and for this specific algorithm that trade looks bad given the above. Open to being wrong if there's a smarter way to share the DP table that doesn't serialize on it, but wanted to lay out the actual tradeoff rather than leave it at "tried it, was slow."

Well, if single-threaded tasks can be cut into reasonable run time (1-2 hours is my personal preference) then there is no big need to do multi-core apps, i agree.. BUT if you just wrap independent single-core processes into one task that allocates multiple of such into one WU, even without any synchronization of this distinguished-point table, that will slightly simplify management (download, upload, boinc lags on many tasks and so on) for crunchers. I bet claude can help with that ;)

---

I crunch for Ukraine

That's the better idea, and it sidesteps the exact problem in my last post: bundle N independent single-core task instances into one BOINC job, each with its own seed and its own DP table, no shared state and no locking at all -- just BOINC's own wrapper app running several child processes and reporting them as one work unit. Real reduction in per-task overhead (one download/upload/scheduler-RPC instead of N), zero synchronization cost, and it doesn't fight the batched-inversion design at all since each child is just running the existing single-core binary unchanged.

I'll build it as a real follow-up (wrapper app + job.xml + a generator change to hand out N seeds per WU instead of 1) -- won't rush it into today's changes since it touches work generation and credit accounting for the live project, but it's a solid, concrete idea and worth doing properly. Will post here once it's up.

Thanks for the explanation. I think I am going to stick with GPU work for this project now I have it up and running with no apparent hit on using the computer for other things.

I observe the same issue on Potamos (sequential keyspace scan) 0.21 (opencl_apple_gpu) task on M4 - percentage resets after suspend/resume

---

I crunch for Ukraine

same issue on Potamos (sequential keyspace scan) 0.05

effectively all my macs are unusable cause they can be on battery from time to time

---

I crunch for Ukraine

I can suggest this as a temporary solution:

Use this code in terminal caffeinate -dimsu

Claude's weekly usage limit has been reached, and GLM is being used for another project—I don't want to mix the two up. I won't be able to fix this issue until Saturday.

---

Thanks. I'll keep this in mind. There is also option to "Activity -> Run Always" in boinc menu but it may drain the battery

If you will be able to cut tasks to be shorter, this will be generally helpful cause it would not be so sad to lose minutes of computation time comparing to hours :)

---

I crunch for Ukraine

In reply to Alperen Yavuz's message of 30 Sep 2026:

I can suggest this as a temporary solution:
Claude's weekly usage limit has been reached, and GLM is being used for another project—I don't want to mix the two up. I won't be able to fix this issue until Saturday.

hey a week ago Anthropic enabled a one-time feature to reset weekly limits. Check if you have it in claude desktop or on web (it was not visible in claude code)

---

I crunch for Ukraine