Can I?
Is there a reason I shouldn't?

---

It depends a bit on the project and whether you are more interested in the science or in credit. Some projects still give credit for tasks returned after the deadline. CPDN is one example. I think WCG does and will use the result if it is returned before the reissued task.

My question if it happening a lot is why are you getting tasks of this nature?

My question if it happening a lot is why are you getting tasks of this nature?

Most likely the user has:
1) Too large of a cache. BOINC request work settings is for more days than the shortest tasks from one of more projects;
2) Computer is not on enough hours per day to complete tasks in a timely manner;
3) A combination of the above two scenarios.

Don't care about credit.
Don't want to contribute resources and have them wasted.
It's not happening a lot. It's just annoying having to watch for it.
A long time ago, it was happening a lot with LHC, and I turned LHC off.
It recently happened wiith BOINC Central where a couple of tasks Estimated Completion jumped to over 9 days.

Cache is a bit larger than default, but not huge.
Computer is on 24/7.

Thanks for the suggestions.

I was hoping there was a switch I could turn on so the problem tasks could be automatically killed and a problem report automatically submitted to the project.

And we have such an option: `max_overdue_days` in cc_config.xml file

---

BOINC maintainer.
For any insight, check my BOINC Development Blog.

Side note: sometime I wonder, why do we write client release notes if nobody reads them?

---

BOINC maintainer.
For any insight, check my BOINC Development Blog.

In reply to Vitalii Koshura's message of 20 Jul 2025:

And we have such an option: `max_overdue_days` in cc_config.xml file

Hmmm, why don't I see that option in the fully populated cc_config.xml file in my 8.3.0 client??

Side note: sometime I wonder, why do we write client release notes if nobody reads them?BOINC maintainer.

Users don't read developer docs for any software. Release notes are developer docs. If you want users to read it, you have to put it in the user docs.

Boinc has different kinds of users System and network engineers have large numbers of computers they administer. Individual users have at most a few computers and they have a wide variety of skill sets. They may not have the foggiest idea where to find the config files and have the software engineering skills and tools necessary to read, understand, and modify them. User docs are needed for all kinds of users.

In reply to Vitalii Koshura's message of 20 Jul 2025:

Side note: sometime I wonder, why do we write client release notes if nobody reads them?

I read them, but if a particular change doesn't affect me, i'm not likely to remember it. Especially if it does end up affecting me 3, 6, 18, 24 months later.
Ans if it doesn't affect me, i generally don't upgrade my Manager (if it's not broken, don't fix it).

---

Grant
Darwin NT.

In reply to drew1horn's message of 20 Jul 2025:

Thanks for the suggestions.

I was hoping there was a switch I could turn on so the problem tasks could be automatically killed and a problem report automatically submitted to the project.

The problem isn't with the project, it's with your system downloading more work than it can handle.
Generally the easiest fix is set a cache size that doesn't cause the issue to occur- whatever the shortest deadline is for projects you are crunching for, set the cache to that value - 1 day.
ie- Shortest deadline of 10 days, set it to 9 days. Shortest deadline is 5 days, set it to 4 days.
And make sure when you set you cache, to set it in the "Store at least" value. The "Store up to an additional" is best set to 0.01 days of work at most.

There are other things that impact deadlines that the Manager can have problems working around- If it is set to "Suspend when non-BOINC CPU usage is above xxx %", any value less than 85% is excessive.
"Use at most 100 % of CPU time" set to anything other than 100% it can take quite a while for things to settle down to give an accurate estimate for processing times.
And if it is set to 100%, but the system is busy doing non-BOINC work, then it can take forever for the manger to adjust to the impact that has on processing work (eg- taking 8 hours to do only 2 hours of actual processing).
And then when people micromanage things, the Manager may never be able to get things to work as they should...

---

Grant
Darwin NT.

Hmmm, why don't I see that option in the fully populated cc_config.xml file in my 8.3.0 client??

I think there are more than a few options for that file that only appear if you put them in manually.

No,

Maybe it is LHC not BOINC Central that is having problems. Most of my tasks are well be haved and run to completion.

This one is running normally and will probably complete successfully.


Application
Theory Simulation 300.98 (vbox64_theory)
Name
Theory_2922-4901269-109
State
Running
Received
Mon 21 Jul 2025 04:18:56 AM MDT
Report deadline
Thu 31 Jul 2025 04:18:54 AM MDT
Estimated computation size
3,600 GFLOPs
CPU time
00:29:53
CPU time since checkpoint
00:00:16
Elapsed time
00:57:32
Estimated time remaining
01:51:07
Fraction done
0.403%
Virtual memory size
1.94 GB
Working set size
667.57 MB
Directory
slots/7
Process ID
4125055
Progress rate
0.360% per hour
Executable
vboxwrapper_26210_x86_64-pc-linux-gnu
Application Name
Theory
Plan Class
vbox64_theory

This one is not.


Application
Theory Simulation 300.98 (vbox64_theory)
Name
Theory_2922-4878753-109
State
Running
Received
Mon 21 Jul 2025 04:18:56 AM MDT
Report deadline
Thu 31 Jul 2025 04:18:54 AM MDT
Estimated computation size
3,600 GFLOPs
CPU time
03:49:34
CPU time since checkpoint
00:00:27
Elapsed time
07:26:01
Estimated time remaining
9d 14:16:33
Fraction done
3.127%
Virtual memory size
1.92 GB
Working set size
667.57 MB
Directory
slots/3
Process ID
4014161
Progress rate
0.360% per hour
Executable
vboxwrapper_26210_x86_64-pc-linux-gnu
Application Name
Theory
Plan Class
vbox64_theory


Application
Theory Simulation 300.98 (vbox64_theory)
Name
Theory_2922-4878753-109
State
Running
Received
Mon 21 Jul 2025 04:18:56 AM MDT
Report deadline
Thu 31 Jul 2025 04:18:54 AM MDT
Estimated computation size
3,600 GFLOPs
CPU time
03:49:34
CPU time since checkpoint
00:00:27
Elapsed time
07:26:01
Estimated time remaining
9d 14:16:33
Fraction done
3.127%
Virtual memory size
1.92 GB
Working set size
667.57 MB
Directory
slots/3
Process ID
4014161
Progress rate
0.360% per hour
Executable
vboxwrapper_26210_x86_64-pc-linux-gnu
Application Name
Theory
Plan Class
vbox64_theory

At this time I have three tasks like the second one. Should I just kill them now, or should we take a closer look?

I have 3 similar tasks that have completed and are ready to report.

I haven't been watching real closely, but they have reported and a few more are ready to report.

And, here are my Cahche Settings

Mon 21 Jul 2025 04:18:33 PM MDT | | - Store at least 0.25 days of work
Mon 21 Jul 2025 04:18:33 PM MDT | | - Store up to an additional 1.00 days of work

In reply to drew1horn's message of 22 Jul 2025:

No,

Maybe it is LHC not BOINC Central that is having problems. Most of my tasks are well be haved and run to completion.

This one is running normally and will probably complete successfully....

...


This one is not.
...

Ok, so the issue is with Tasks that are taking much, much longer than they should be.
It looks like there are several issues here-

One is the amount of CPU time the application is getting- 30 min CPU time for the first task, however it's taken almost 1 hour in real time to do that.
The second Task has done 3hrs 50min work, but it has taken it almost 7.5hrs to do it.

For whatever reason, it's taking your system 2 hours of real time to do only 1 hours worth of processing.
For a normal (non-Virtual Machine arrangement), such an issue would indicate an over committed system (ie other processes using CPU time, not leaving time for the BOINC science application to run). Or having "Use at most xxx% of CPU time" set to 50% (really, it should be 100%- if your system has cooling issues, fix them, just or reduce the number of cores/threads being used).


The other issue is just how much work your system is actually doing when it is processing a Task both of the Tasks you posted are being processed at the same rate (the second and third one you posted are the same) 0.360% per hour- roughly 11.6 days to complete the Task.

I suggest you check with the project forums, and try to figure out just what is going on there- 50% of the time the application is running, it's not actually doing any work- the clock is just ticking.
Also, your system is processing work so slowly, there is no chance of doing it by the deadline- 10 day deadline, 11.6 days to process (at best).

---

Grant
Darwin NT.

In reply to drew1horn's message of 22 Jul 2025:

I haven't been watching real closely, but they have reported and a few more are ready to report.

And, here are my Cahche Settings

Mon 21 Jul 2025 04:18:33 PM MDT | | - Store at least 0.25 days of work
Mon 21 Jul 2025 04:18:33 PM MDT | | - Store up to an additional 1.00 days of work

If you want one days cache, then

Store at least 1.0 days of work
Store up to an additional 0.01 days of work

If you want 1.25 days cache, then

Store at least 1.25 days of work
Store up to an additional 0.01 days of work

The way you have it set now, what happens is you will get 1.25 days of work, then the cache will run down until it drops below 0.25 days, then it will load up again to get 1.25 days of work, then the cache will run down until it drops below 0.25 days, etc, etc.
If you set it to "Store at least 1.25 days of work" and "Store up to an additional 0.01 days of work" that will result in it getting 1.25 days of work, and when it drops below 1.25 days, it will top it up to give you at least 1.25 days of work.

---

Grant
Darwin NT.