I suspect, and it's only a suspicion, that the reason invoking the "ghost recovery" process is often successful in retrieving new tasks, even when no ghosts are present, is that a different timer is used, or at least a different, longer time interval. That "ghost recovery" process would, by necessity, require a database query in order to determine what tasks the server thinks are on hand for the requesting host. The results of that query then would have to be compared, task by task, against the tasks identified in the "<other_results>" section of the scheduler request, in order to see if any are missing and need to be resent. It would make sense to me (if making sense matters) that a longer response time might be allowed in order to accomplish that database retrieval and comparison, thus perhaps providing an extra cushion for normal scheduler operations.

I like your deduction. Makes sense to me that there is another timer mechanism in play for the "ghost recovery" protocol.

---

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

A proud member of the OFA (Old Farts Association)

Another consideration is the maximum number of tasks sent per request can be set on the sever.
Several years ago the max number of AP tasks per request was reduced so it would be harder for users to stockpile them.
It went from being able to get 100 at a time to ~7.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I suspect, and it's only a suspicion, that the reason invoking the "ghost recovery" process is often successful in retrieving new tasks, even when no ghosts are present, is that a different timer is used, or at least a different, longer time interval. That "ghost recovery" process would, by necessity, require a database query in order to determine what tasks the server thinks are on hand for the requesting host. The results of that query then would have to be compared, task by task, against the tasks identified in the "<other_results>" section of the scheduler request, in order to see if any are missing and need to be resent. It would make sense to me (if making sense matters) that a longer response time might be allowed in order to accomplish that database retrieval and comparison, thus perhaps providing an extra cushion for normal scheduler operations.

See thats the thing, the "ghost recovery" procedure has the same timeouts as a normal scheduler request.
See the client in its scheduler request sends a list of tasks that it is currently processing. The logic of the scheduler, in the db using the count() SQL statement sees that the host has reached the 100WU per cpu + 100WU per gpu limit, when it sees this, the scheduler decides it is absolutely necessary to query the db. And this is probably the statement that it would execute:

SELECT id, workunitid, name, hostid FROM result WHERE hostid='Your host id'

I've skimmed the code, so that SQL statement is a guess.
And the parsing of what it received from doing that, takes up the majority of its time, resulting in you recovering 20 WU only. I'd hazard a guess it times out

Oh the server that the scheduler is running on is a synergy.
Which has a spec according to the SSP page: Intel Server (2 x hexa-core 2.53GHz Xeon, 96 GB RAM)
I'd hazard a guess the specs of this server are:
Dual Intel Xeon E5649 2.53Ghz with max turbo upto 2.93Ghz on the LGA1366 socket
96GB of DDR3 1066 Mhz memory

Ah, we're back.
The forums went from being slower than a year of Sundays, to the Web site vanishing completely for a while there.

---

Grant
Darwin NT

Getting "Project is temporarily shut down for maintenance" messages in my event log. All looks OK on the web site. Anybody elese experiencing this?

Yes, here too.
I thought I over slept by 4 days ;P

Yes, just noticed a few finished tasks, going nowhere. Tried to 'update'.....no luck. Been a while since we had server trouble on a Friday afternoon (here, that is)!

---

Don't take life too seriously, as you'll never come out of it alive!

Getting "Project is temporarily shut down for maintenance" messages in my event log. All looks OK on the web site. Anybody elese experiencing this?

Yes.....it's not just you.
I just noticed that all my rigs have not reported for about half an hour. Which is about the time that server message and backoff was sent out.

SSP looks OK as of this post. And I just hit the update button on my daily driver.......reported and got new tasks. So, it looks like the coast is clear again.
I'll just let the rest of my rigs time out by themselves.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I had a 30 minute backoff on all machines and I just updated and started getting task again. So a short lived event.

---

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

A proud member of the OFA (Old Farts Association)

I had a 30 minute backoff on all machines and I just updated and started getting task again. So a short lived event.

. . Well I was blissfully asleep through that event, but right now the servers are very reluctant to this rig {i5-6600 with 2 x 970s} any work, I had to tickle its tonsils very hard to refill my cache to only almost full, still 20 or so down and it won't send any more ...

Stephen

??

Would appear to be a lack of nvidia GPU work being available.
My caches are down a bit too.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Yes, seeing the same. Down about 250 tasks on the linux cruncher and it sent (4) after the ghost recovery protocol. Must not have any Nvidia tasks.

---

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

A proud member of the OFA (Old Farts Association)

Yes, seeing the same. Down about 250 tasks on the linux cruncher and it sent (4) after the ghost recovery protocol. Must not have any Nvidia tasks.

That or the feeder is not fast enough to refill the buffer

It seems the RTS is full of Arecibo VLARs. The only CPU tasks I'm getting are Arecibo VLARs and the numbers on the Arecibo splitters aren't changing much even though some of the files are small. Someone needs to add some more Arecibo files and hope a splitter jumps on a new file.

Yep, lots and lots of Arecibo VLARs. Even my machines are having difficulty getting new tasks, and my #1 cruncher actually got down to its last GPU task, the first time I can recall that happening. I just went ahead and rescheduled all the available guppis and non-VLAR Arecibo tasks from the CPU to the GPU queue. That freed up enough CPU queue space to be able to accept a bunch of Arecibo VLARs which, in turn, seemed to let a bunch of guppis and Arecibo non-VLAR tasks loose. It looks like that machine is slowly starting to rebuild the GPU queue but who knows how long that'll last. If I have to, I'll just move Arecibo VLARs over to the GPUs. I don't think they do all that badly with the Special App.

The logjam of Arecibo VLARs may have finally broken up. I just got a 154 task slug of BLCs on the Ryzen system. Hope that occurs for the other crunchers.

---

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

A proud member of the OFA (Old Farts Association)

I was just thinking ... damn that Keith for saying there was not enough BLC files for his Ryzen.
I have more than enough to do my CPUs.

Not very many Arecibo VLAR's here, but I do have heaps of GBT and some normal Arecibo work. ;-)

Cheers.

Murphies Law maybe.
90% Arecibo on my CPU and 90% GBT on my GPU whilst i would like it vice versa.

---

With each crime and every kindness we birth our future.

Murphies Law maybe.
90% Arecibo on my CPU and 90% GBT on my GPU whilst i would like it vice versa.

For me it's generally my slower system gets mostly GBT work, and my faster system mostly Arecibo.

---

Grant
Darwin NT