At the moment on my system, 5 workers are executing tasks with Wednesday (Feb 4 2026) deadlines. Then there are 6 Wednesday tasks that have yet to start, then 10 Thursday tasks yet to start, followed by no Friday tasks yet to start. Then there are 15 running tasks with Saturday deadline, followed by several Saturday tasks yet to start, then several Sunday tasks yet to start.

I do not understand why the Saturday tasks have started when there are unstarted Wednesday and Thursday tasks?

I do notice that the executing and unstarted Wednesday and Thursday tasks have names ending in _1 whereas the started Saturday tasks have names ending in _0

At the moment on my system, 5 workers are executing tasks with Wednesday (Feb 4 2026) deadlines. Then there are 6 Wednesday tasks that have yet to start, then 10 Thursday tasks yet to start, followed by no Friday tasks yet to start. Then there are 15 running tasks with Saturday deadline, followed by several Saturday tasks yet to start, then several Sunday tasks yet to start.

I do not understand why the Saturday tasks have started when there are unstarted Wednesday and Thursday tasks?

I do notice that the executing and unstarted Wednesday and Thursday tasks have names ending in _1 whereas the started Saturday tasks have names ending in _0

I have noticed this behavior for many years and I believe it's a feature of the BOINC manager. The manager executes tasks based on when the manager receives the tasks and not the actual deadline. However, it will start running the tasks with the earlier deadlines when it gets close to the deadline - I have literally seen the manager suspend all tasks that were currently running in order to run the tasks ending in _1.

I do not understand why the Saturday tasks have started when there are unstarted Wednesday and Thursday tasks?

-- Due to WU priority. Gerasim server log:

<wu_addition>
<archive_name>sf7_cv11_1600k-1700k.zip</archive_name>
<app_name>Get Decic Fields</app_name>
<n_wu_processed>100000</n_wu_processed>
<n_wu_inserted>100000</n_wu_inserted>
<start_time>01 Mar 2026, 19:43:57</start_time>
<end_time>01 Mar 2026, 19:46:15</end_time>
<duration>2 minutes, 18 seconds</duration>
</wu_addition>

-- By default, the WU priority and tasks (child) has priority value = 1000.
-- During WU processing, Eric has ability assign any value to WUs priority.
-- Gerasim will follow these instructions immediately.
-- "_0" has no meaning for Gerasim.

1 Your system is overcommitted- ie it's busy trying to do other work as well as BOINC work.
BOINC Tasks are set to run at a low priority level, so they make room for other things running on your computer. That's why it takes your system 7hrs 26min to do 6hrs 40min of actual work (eg Task 282411806)

2 And while your average turnaround time is 1.1 to 1.2 days, there are Taks (such as the one i referred to), which are taking you almost 2 days (or more) to return.

Normal Tasks have a 6 day deadline. Re-sends (those where a Task has been sent out, but no Valid result was returned by the deadline) have a 3 day deadline.

The BOINC Manager does it's best to return all downloaded work before the deadline is reached; so if there are Tasks that are in danger of missing their deadlines, it will start processing those before previously downloaded Tasks. If things are really bad, it will even stop processing currently running Tasks and run those at risk of being late (and if they are late, they may not get Credit).


Reduce the number of cores/threads being used by BOINC (or find out what else is using so much of your CPU time).
If your system is set to suspend computation while the computer is in use, change it to not suspend.
But mostly- Set a smaller cache eg
1 day + 0.01 additional days.

That way, you won't run into deadline issues, and that way BOINC will continue to run in it's default mode- which is First in, First out.

---

Grant
Darwin NT, Australia.

-- By default, the WU priority and tasks (child) has priority value = 1000.

This only applies to Windows systems.
Sandra Roberson uses Darwin (Darwin 25.3.0), a Unix-like operating system.
There, this value is significantly higher, as far as I remember.

> Normal Tasks have a 6 day deadline. Re-sends (those where a Task has been sent out, but no Valid result was returned by the deadline) have a 3 day deadline.

I finally understand. The system is sending me a mix of tasks, including some that are re-sends because they timed out *on other people's systems* . Those re-sends have shorter deadlines.

This is not the case that tasks are timing out *on my system* .

I finally understand. The system is sending me a mix of tasks, including some that are re-sends because they timed out *on other people's systems* . Those re-sends have shorter deadlines.

Yep.

This is not the case that tasks are timing out *on my system* .

Correct.
The resends occurred because they timed out (missed the deadline) on those other systems, not yours.


It looks like you started doing Numberfields work on that computer on the 26 Feb?

As work is returned, over time the BOINC Manager will monitor how many hours a day the computer is running, and when running how many of those hours it is able to process Tasks and eventually it will settle down- if your cache is set for around 3 days or so, then you may continue to see some more recently downloaded Tasks being done before earlier downloads in order to avoid missing deadlines.

If it's set for less than 2 days, then eventually that behaviour will cease, and it will just process the work in the order it was downloaded (First In, First Out- unless of course there ends up being a day or two where the computer isn't running and no Tasks can be processed, so then it'll concentrate on those most at risk of missing the deadline until it catches up again...).

---

Grant
Darwin NT, Australia.

> ... Those re-sends have shorter deadlines.
...

This is a bit different.
The joker played his cruel joke.

What do I mean?
The server operates on numbers.
That's what it does the fastest.
For example:
https://numberfields.asu.edu/NumberFields/result.php?resultid=282844235

Sent 	27 Feb 2026, 12:25:22 UTC
Report deadline 	3 Mar 2026, 12:25:22 UTC

What is the date "27 Feb 2026, 12:25:22 UTC" from the server side?
It's just a timestamp number with a value of 1772184322
By default, a task is generated with a deadline of 7 days.
7 days is 604800 seconds (604800 / 60sec / 60min / 24hours = 7days).

It is the number 604800 that the server remembers for each task.
(Unless a different developer is specified when generating tasks.)

The base number for calculating the number of days is 31.
The number 32 is impossible in our year.
But the numbers 31, 30, 28, and 29 are possible (for a leap year).
Moreover, 31 is the most common number in the year (there are seven of them).

There are 86,400 seconds in a day.
Now some simple arithmetic:

27.02.2026 12:25:22 = 1772184322

1772184322 + 86400 = 1772270722 28.02.2026 12:25:22
1772270722 + 86400 = 1772357122 29.02.2026 12:25:22
1772357122 + 86400 = 1772443522 30.02.2026 12:25:22
1772443522 + 86400 = 1772529922 31.02.2026 12:25:22
1772529922 + 86400 = 1772616322 01.03.2026 12:25:22
1772616322 + 86400 = 1772702722 02.03.2026 12:25:22
1772702722 + 86400 = 1772789122 03.03.2026 12:25:22

What time did we see in the "Report deadline" field?
And it completely coincides with the calculation I showed using basis 31.
"1772789122 03.03.2026 12:25:22" == "27 Feb 2026, 12:25:22 UTC"

Nothing complicated.
I understand that this is unusual for you.

This is not the case that tasks are timing out *on my system* .

You understood everything correctly.

P.S.
By the way, I made a mistake too.
I entered the wrong date.
The correct version would be:
"1772789122 03.03.2026 12:25:22" == "3 Mar 2026, 12:25:22 UTC"
Sorry.

Too late to edit things, but the initial deadline is 7 days (not 6 as i kept posting for some odd reason).

---

Grant
Darwin NT, Australia.

Too late to edit things, but the initial deadline is 7 days (not 6 as i kept posting for some odd reason).

Technically speaking, the deadline is 6 days, but there is a 1 day grace period before the WU gets resent to someone else. So you have 7 days, but if you don't start it within 6 days the manager usually aborts it.

Too late to edit things, but the initial deadline is 7 days (not 6 as i kept posting for some odd reason).

Technically speaking, the deadline is 6 days, but there is a 1 day grace period before the WU gets resent to someone else. So you have 7 days, but if you don't start it within 6 days the manager usually aborts it.

Pretty sure the only non-user cancellation is by server. BOINC Manager AFAIK will not cancel them (by default - there might an option for this).

Too late to edit things, but the initial deadline is 7 days (not 6 as i kept posting for some odd reason).

Technically speaking, the deadline is 6 days, but there is a 1 day grace period before the WU gets resent to someone else. So you have 7 days, but if you don't start it within 6 days the manager usually aborts it.

Pretty sure the only non-user cancellation is by server. BOINC Manager AFAIK will not cancel them (by default - there might an option for this).

I guess it's possible the server could be telling the client to abort unstarted work units that are past their deadline. But according to Google Gemini:

Yes, the BOINC Manager can and does automatically abort work units that it determines cannot be finished before their deadline, particularly if they are significantly past due or stalled.

I guess it's possible the server could be telling the client to abort unstarted work units that are past their deadline. But according to Google Gemini:

Yes, the BOINC Manager can and does automatically abort work units that it determines cannot be finished before their deadline, particularly if they are significantly past due or stalled.

Gemini is technically correct, but it is also wrong.

There have been cases where projects have had major unexpected extended downtime, and the project configured the Scheduler to extend the deadlines for all previously issued Tasks before bringing the servers back on-line again.
That way even though it might have been weeks (or longer) since the deadlines passed, all systems that processed those tasks with the past due deadlines were able to get Credit if they validated once they had been reported.
Even though the deadline was long past, the BOINC Manager didn't drop the Tasks from the systems. They were still there to process, because it couldn't contact the project servers.


Yes, the BOINC Manager does cancel Tasks that haven't been started by their deadline, but it can only do so after it has contacted the project server and got a valid response from the Scheduler.
The deadline may pass, but unless the Scheduler tells the Manager to drop the Task, it won't; and BOINC will continue to process any Tasks that are past their deadline.

---

Grant
Darwin NT, Australia.

Yes.
The server execution map you wrote is correct.
The AI ​​often provides an overly general situation.
And it doesn't reflect reality.
A lot of effort and clarification from the person asking the question is required for the AI ​​to provide the correct answer.

To abstract and simplify, it works out roughly like this:
1. Generate a task for the client
2. Publish the task for the client
3. The client accepts the task for calculation
4. The client returns the task
5. The server checks the task
6. The server marks it as completed
7. The server deletes the records for the completed task.

If the client doesn't return the task from step 4 due to a timeout, then this task is re-entered into step 2 with a different [number|name].

The dates are not important in this case.
A very simple condition is met: the task is calculated or not.

Accordingly, a task can be generated in the current year, but it may be calculated in one or two years.
And that's normal.