50% of the load hasn't been removed.

Each time i asked in the past what was the way to measure the load on the DB someone tell is: queries/second

Was in the range of 1200-1500 and now is at 508 so by my math the number downs even mora than 50%

Sorry, i though you were referring to the numbers of Tasks.
Yes, the number of queries per second is down, but much of that load would have been from the splitting of new work, and the high return rate of completed work. But the fact is the database is still bloated, and even though there's more CPU resources, the I/O bottleneck remains, so the Assimilation backlog remains, so everything remains backlogged.
But slowly, ever so very slowly, the backlog is clearing,

---

Grant
Darwin NT

since the load on the servers is much less now, the assimilators can now actually make some progress. thats why you see the numbers finally on a steady decline for once.

it will go slow for a while, and speed up as more and more resources are freed up. the sink is finally draining faster than it is being filled (mainly because the faucet was reduced from full open to just a steady trickle)



note how the validation (results) queue is decreasing at a faster rate than the assimilation (workunits) queue. for every entry removed from the assimilation queue, ~2.2 entries are removed from the validation queue. like we've been saying all along.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

It may have taken a PhD to write BOINC, but it shouldn't require one to configure it.
This thing load-shares like three teenagers and a dog in the back seat of the car.
Just sayin' ...

---

It may have taken a PhD to write BOINC, but it shouldn't require one to configure it.
This thing load-shares like three teenagers and a dog in the back seat of the car.
Just sayin' ...

I suspect that when developing it they had no idea of the ways in which people would try to get things to run. And many of the options can conflict with other options, combined with Anonymous Platform support, the way Resource sharing is determined, variable processing times & hugely varying deadlines and hardware requirements along with incredibly small to ridiculously huge caches and people using ncpus & other such settings in ways the developers never imagined in their wildest dreams (worst nightmares?) results in things not happening in quite the way people might expect them too, and certainly not within their expected time frame- which generally seems to be immediately, if not retrospectively.

---

Grant
Darwin NT

It may have taken a PhD to write BOINC, but it shouldn't require one to configure it.
This thing load-shares like three teenagers and a dog in the back seat of the car.
Just sayin' ...

I suspect that when developing it they had no idea of the ways in which people would try to get things to run. And many of the options can conflict with other options, combined with Anonymous Platform support, the way Resource sharing is determined, variable processing times & hugely varying deadlines and hardware requirements along with incredibly small to ridiculously huge caches and people using ncpus & other such settings in ways the developers never imagined in their wildest dreams (worst nightmares?) results in things not happening in quite the way people might expect them too, and certainly not within their expected time frame- which generally seems to be immediately, if not retrospectively.

As I said, like 3 teenagers and a dog. :)

---

It looks like I got
11 MB's on April 2.
19 MB's on the 3rd.
1 on the 4th
1 on the 5th
3 on the 6th (so far).

Tom

---

A proud member of the OFA (Old Farts Association).

BOINC v7.16.5/.6 has been released, but looking at the Release notes i can't see any mention of a "Finish file present too long" fix.

Changes in 7.16
If output file is missing on startup, flag task as error.
Let project specify directories in logical file names.
Fix security vulnerability involving logical file names.
Make "reread config files" work for ncpus.
Support fetch of files over GUI RPC; allow projects to supply their own web-based GUI.
FreeBSD: check for AVX
Support GUI RPCs as HTTP Post requests.
Register user consent to terms of use.
Enable "Other options" in simple view if no client connected.
Clear "vm_extensions_disabled" flag on startup.
Fix work fetch bug when max_concurrent used.
Unsuspend jobs before telling them to quit.
Sanity-check job runtime limits.
Fix overflow in OpenCL GPU FLOPS calculation.
Windows: show processor group info at startup
Fix stall if --skip_cpu_benchmarks
Fix crash in RSS feed fetch
Windows: fix GUI RPC password generation when running in a VM
Windows: make --dir work

---

Grant
Darwin NT

https://github.com/BOINC/boinc/pull/3019/commits
Merged JuhaSointusalo merged 1 commit into master from dpa_finish_file on Mar 30, 2019
Since BOINC 7.16.5 was build from master, the fix was included.
master (#3019) server_release/1.2/1.2.1 ... client_release/7.16/7.16.1

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

https://github.com/BOINC/boinc/pull/3019/commits
Merged JuhaSointusalo merged 1 commit into master from dpa_finish_file on Mar 30, 2019
Since BOINC 7.16.5 was build from master, the fix was included.
master (#3019) server_release/1.2/1.2.1 ... client_release/7.16/7.16.1

So it got rolled in to the

If output file is missing on startup, flag task as error.

fix?

---

Grant
Darwin NT

Has the server backoff after a request gone up from 10min to 30min now?
10min since last request, showing 20min till next one one in Project Status column.

---

Grant
Darwin NT

Just did one, and got the 10 minute server backoff.

Meow.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Just did one, and got the 10 minute server backoff.

Meow.

Oh well, 7min to go, we'll see what happens next.

---

Grant
Darwin NT

Just did one, and got the 10 minute server backoff.

Meow.

Oh well, 7min to go, we'll see what happens next.

Another 30min delay after the next request.
Better than the 1hr+ delays the Manager starts to do.

---

Grant
Darwin NT

There must have been a change made serverside.
I am getting a 30 minute backoff now too.

Meow.

---

"Time is simply the mechanism that keeps everything from happening all at once."

https://github.com/BOINC/boinc/pull/3019/commits
Merged JuhaSointusalo merged 1 commit into master from dpa_finish_file on Mar 30, 2019
Since BOINC 7.16.5 was build from master, the fix was included.
master (#3019) server_release/1.2/1.2.1 ... client_release/7.16/7.16.1

So it got rolled in to the

If output file is missing on startup, flag task as error.

fix?

I guess so. That is what actually happens with a "finish file present too long" error. They just dumbed down the description instead of tying it directly to the error description. This is DA's description of the error and the fix in the pull request.

When an app finishes, it writes a "finish file",
which ensures the client that the app really finished.

If the app process is still there N seconds after the finish file appears,
the client assumes that something went wrong, and it aborts the job.

Previously N was 10.
This was too small during periods of heavy paging.
I increased it to 300.

It has been pointed out that if the app creates the finish file,
and its output files are present,
it should be treated as successful regardless of whether it exits.
This is probably true, but right now we don't have a mechanism
for killing a job and marking it as success.
The longer timeout makes this moot.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I guess so. That is what actually happens with a "finish file present too long" error. They just dumbed down the description instead of tying it directly to the error description. This is DA's description of the error and the fix in the pull request.

When an app finishes, it writes a "finish file",
which ensures the client that the app really finished.

If the app process is still there N seconds after the finish file appears,
the client assumes that something went wrong, and it aborts the job.

Yeah, i saw his description.
And what he describes (which is the "Finish file present too long" problem) is different to "If output file is missing on startup, flag task as error."
The second one is "if a file is missing, then and error has occurred" the first one "if a process is still going a certain time after the file is written, the Task is aborted". To me they are two different issues- one is a missing file, the other the file is there. One is the result of an error, the other results in an error.


Will just have to see if any "Finish file present too long" errors show up or not on systems with the new Manager.

---

Grant
Darwin NT

Just got notified of a Boinc Manager update for my Windows box. Downloaded the VM version. Maybe I will explore running Cosmology@Home which is a VM only project on it.

Tom M

---

A proud member of the OFA (Old Farts Association).

Just got notified of a Boinc Manager update for my Windows box. Downloaded the VM version. Maybe I will explore running Cosmology@Home which is a VM only project on it.

Tom M

Just FYI, if it's 7.16.5 x64 you've updated to, be advised I've been having nothing but trouble with that on my Win box with Einstein jobs, and after 2 trys I just fell back to 7.14.2. Seems CPU jobs just halt. Also apparently trashed the history, to the point where it''s saying I reached my max of 480 tasks per day and threw me into a 24 hour project back-off.

---

Will just have to see if any "Finish file present too long" errors show up or not on systems with the new Manager.

I've been running the 7.16 branch clients for a long time now. Haven't seen a finish file present error since.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Just got notified of a Boinc Manager update for my Windows box. Downloaded the VM version. Maybe I will explore running Cosmology@Home which is a VM only project on it.

Tom M

Just FYI, if it's 7.16.5 x64 you've updated to, be advised I've been having nothing but trouble with that on my Win box with Einstein jobs, and after 2 trys I just fell back to 7.14.2. Seems CPU jobs just halt. Also apparently trashed the history, to the point where it''s saying I reached my max of 480 tasks per day and threw me into a 24 hour project back-off.

My Windows box is mostly not running and except for S@H its not set to allow any new tasks so I can't offer any opinion. Maybe over the Easter weekend I will "play" with it.
I am interested to see if with the VM installed does using a VM-based project become "turn key"?

Tom M

---

A proud member of the OFA (Old Farts Association).