And there is now a fix for the AMD RX 5000 card issues.

They can force only 'vanilla' hosts to upgrade their apps. So they can't really revert the triple validation kludge for overflow results before enough of the anonymous platform hosts have updated their apps to make the risk of a task getting sent to two bad hosts tiny enough to be acceptable.

Unless they can 'blacklist' amd gpus from receiving the _1 if the corresponding _0 was sent to one. But I don't think the system supports this because if it did, they would have already done it instead of using this triple validation kludge - which isn't even 100% watertight because there's still the risk of all three going to bad hosts.

---

I am waiting and waiting to have the website confirm that I have a full cache.

Everything is running Seti@Home except for three weather forecast tasks from WCG.

Eyeballing it looks like I have a full set of cpu tasks and a less than full set of gpu tasks. But all the gpus are engaged and I think I may have 150 gpu tasks so hopefully it will stay that way.

Apparently the Replica DB is "just a bit behind". It just reported I have 6 tasks in progress.

I know I have to take off my shoes to count past 10 but I am sure I have more than "6" :)

Here it is Sunday morning and I/we? are finally get a steady flow of tasks?

Tom

---

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

Now, if the "Results returned and awaiting validation" were on the same graph as the "Results out in the field" for both for MB & AP it'd be perfect

Actually one of the more interesting graphs would be ts SUM of 'Results ready to send', 'Results out in the field', 'Results returned and awaiting validation' and 'Results waiting for db purging' for both MB & AP. That is all eight fields in one sum.

This would be the number of results in the database. The value that Eric said has to be kept under 20 milllion to avoid the result table spilling out of RAM. It is now 18.9 milllion.

Those 71 ancient zombie S@Hv7 results appear to have finally been purged!

---

I am waiting and waiting to have the website confirm that I have a full cache.

Do what I did: Write a program that reads the client_state.xml and reports the number of tasks for CPU and GPU. That way you can easily see how full your queues are and you don't need the website for that, so it works even during the out(r)ages.

And the data will always be fresh no matter how behind the relica db is.

---

I think BoincTasks can do that, as well.

I think BoincTasks can do that, as well.

Quite well, in fact.

---

And, at least for the moment, the floodgates appear to have opened.

---

Something has changed. The floodgates are wide open but the assimilation queue is still getting smaller.

---

I'm not seeing the '71' under the S@H V7 column on the server status page. Did those finally get cleaned up in the dbase?

---

~Chris

02-Feb-2020 15:51:01 [SETI@home] Sending scheduler request: To fetch work.
02-Feb-2020 15:51:01 [SETI@home] Requesting new tasks for CPU and AMD/ATI GPU
02-Feb-2020 15:51:06 [SETI@home] Scheduler request completed: got 124 new tasks

UTC+1 ^^

---

I'm not seeing the '71' under the S@H V7 column on the server status page. Did those finally get cleaned up in the dbase?

It appears they did... the purging queue has fallen by half, so work generation is back as the result table is well below 20M.

---

I'm not seeing the '71' under the S@H V7 column on the server status page. Did those finally get cleaned up in the dbase?

It appears they did... the purging queue has fallen by half, so work generation is back as the result table is well below 20M.

Maybe is time to start to cut the timeline of the WUs and some changes in the way the work is distributed like sending the resends to the fastest hosts to clear them ASAP. Or we will be trapped on an endless loop of no new work each time the total reaches 20 MM.

---

Or we will be trapped on an endless loop of no new work each time the total reaches 20 MM.

Possible explanation of why this has only been happening recently here.... Briefly: Quorum=3 for overflows coupled with BLC35 files which generate little except overflows.

---

Maybe it time to start to cut the timeline of the WUs and some changes in the way the work is distributed like sending the resends to the fastest hosts to clear them ASAP.

Again NOT the fastest but the ones with the shortest average turnaround time. Slow host with a tiny cache can return the result faster than a fast host with a huge spoofed cache.

One thing that could prevent this from happening again is if the system monitored the rate of overflows returned and when any file being split exceeds some threshold, that file would be heavily throttled so that it continues being split but would produce only a small percentage of all the workunits.

Or this could even happen without any monitoring if the different splitters split different files instead of all bunching up on the same file. So if some file (or a few files) produced an overflow storm, the storm would be diluted by all the other splitters splitting clean files. But I don't know how this would affect the splitter performance. Spreading out could be faster or slower than bunching up.

---

Again NOT the fastest but the ones with the shortest average turnaround time. Slow host with a tiny cache can return the result faster than a fast host with a huge spoofed cache.

Sorry the meaning was lost in the translation. For me fastests host are the ones with the shortest average turnaround time (less than 1 day). They could clear the WU in very little time and help to reduce the DB size. Obviusly the WU must be sended with a very small death time line (less than 3 days in this case) .

The way is done now, by sending the WU to any hosts (with a long death time line) just make the DB size problem even worst.

---

I think BoincTasks can do that, as well.

I agree. It would be good if boinc tasks or another piece of software could push short tasks to the front of the queue. Does anybody know of any software that does this?

---

Better solution: if you can detect short tasks without running them, why not just abort them?
Can Boinc Tasks do this? Could the servers?

---

Better solution: if you can detect short tasks without running them, why not just abort them?
Can Boinc Tasks do this? Could the servers?

The only known way is to run them. For a short time, like the time taken on a 2060 GPU, or better, for bomb to be -9ed.
We don't know how many tasks are sent/day but we do know how many are returned/hr.

Average tasks returned per hr * 24 * short time on GPU / 86400 (s in day) = GPU's needed

Sun 02 Feb 2020 06:16:57 PM CST | SETI@home | Scheduler request completed: got 92 new tasks

Yum! Something to crunch ;)

Tom

---

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

Looks like more trouble. About 30 minutes ago the Website got very Slow and the Scheduler checked out;

Mon Feb 3 01:08:50 2020 | SETI@home | [sched_op] Starting scheduler request
Mon Feb 3 01:10:47 2020 | SETI@home | Scheduler request failed: HTTP internal server error
Mon Feb 3 01:10:47 2020 | SETI@home | [sched_op] Reason: Scheduler request failed
Mon Feb 3 01:13:08 2020 | SETI@home | Sending scheduler request: To report completed tasks.
Mon Feb 3 01:14:23 2020 | SETI@home | Scheduler request failed: Couldn't connect to server
Mon Feb 3 01:22:01 2020 | SETI@home | [sched_op] Starting scheduler request
Mon Feb 3 01:23:15 2020 | SETI@home | Scheduler request failed: Failure when receiving data from the peer
Mon Feb 3 01:23:15 2020 | SETI@home | [sched_op] Reason: Scheduler request failed
Mon Feb 3 01:34:15 2020 | SETI@home | [sched_op] Starting scheduler request
Mon Feb 3 01:36:57 2020 | SETI@home | Scheduler request failed: HTTP internal server error
Mon Feb 3 01:36:57 2020 | SETI@home | [sched_op] Reason: Scheduler request failed

Just when everything was working well...