Something screwy going on. :-( Cache empty.

27/10/2018 01:48:13 | SETI@home | Sending scheduler request: To report completed tasks.
27/10/2018 01:48:13 | SETI@home | Reporting 1 completed tasks
27/10/2018 01:48:13 | SETI@home | Not requesting tasks: don't need (CPU: job cache full; NVIDIA GPU: )

I'm not having a problem. As they say on "IT Crowd" - have you tried turning it off and on again ?? sorry if this is a flip answer, I truly hope you figure it out. Maybe more diagnostic messages would be helpful ??

Something screwy going on. :-( Cache empty.

27/10/2018 01:48:13 | SETI@home | Sending scheduler request: To report completed tasks.
27/10/2018 01:48:13 | SETI@home | Reporting 1 completed tasks
27/10/2018 01:48:13 | SETI@home | Not requesting tasks: don't need (CPU: job cache full; NVIDIA GPU: )

. . Have you accidentally set your work request size to something ludicrously small? Try setting your work request to 10 days with additional work to 10 days as well. If that doesn't prompt some downloads then you seriously have a problem.

Stephen

??

Or are you running additional projects that have a large debt to be paid and that is what is blocking getting additional Seti work. If I let Einstein grab too much work, the immediate effect on my hosts is to throttle Seti work down to a single task every 15 requests for work. The consequence of that is my Seti caches rapidly emptying and not being refilled. Abort the abundance of Einstein work and Seti immediately refills the entire cache limit.

---

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

A proud member of the OFA (Old Farts Association)

additionnal work is not a setting for increasing WU cache, but an option to say, " ask server every " additionnal time " you set ^^

for example, if you set 0.01 to " additionnal work " it means, ask server every 15mn :D

---

Haven't touched settings for a considerable time.
Not running other projects for some time.
Got several wu's about 8am & only getting one at a time every time a wu is completed & reported. What's happened to the 100 wu limit(only have 9 atm)? How can the project report the cache is full when it is empty?

Set <sched_op_debug> in Event Log options (Ctrl+Shift+F). and read the numbers. If that doesn't explain it, set <work_fetch_debug>. If you need help in analysing the log, please start a separate thread - it sounds like a problem at your end, not a sever problem.

Done.

Haven't touched settings for a considerable time.
Not running other projects for some time.

Your system shows it's got plenty of Beta AP work.

It takes over 24 hours for you to process 2 AP WUs with the SSE application, and well over 2 days for a single AP WU with the v7.00. You've got 6 SSE & 5 v7.00 WUs in progress, so that makes almost 17 days worth of AP work on your system at present. And it looks like almost 2 days worth of MB worth. That's almost 20 days worth of work, which is the maximum possible cache setting.

Edit- noticed different application runtimes & therefore cache size.

---

Grant
Darwin NT

Haven't touched settings for a considerable time.
Not running other projects for some time.

Your system shows it's got plenty of Beta AP work.

It takes over 24 hours for you to process 2 AP WUs with the SSE application, and well over 2 days for a single AP WU with the v7.00. You've got 6 SSE & 5 v7.00 WUs in progress, so that makes almost 17 days worth of AP work on your system at present. And it looks like almost 2 days worth of MB worth. That's almost 20 days worth of work, which is the maximum possible cache setting.

Edit- noticed different application runtimes & therefore cache size.

. . Well spotted Grant ...

Stephen

:)

There is a bunch of noisy files now.
Received last hour is up to 164k and climbing.
I hope this doesn't last long.

There is a bunch of noisy files now.
Received last hour is up to 164k and climbing.
I hope this doesn't last long.

Now 169k.
This is really going to test the servers.

---

Grant
Darwin NT

There is a bunch of noisy files now.
Received last hour is up to 164k and climbing.
I hope this doesn't last long.

It certainly has been a while since we have seen a high return rate

---

Now 169k.

180k, but it seems to have levelled off there.

---

Grant
Darwin NT

Now 169k.

180k, but it seems to have levelled off there.

Spoke too soon- now over 186k, splitter output has fallen off & Ready-to-send buffer is starting to empty.

---

Grant
Darwin NT

198K now.

More than double our presnt usual load.
At least the splitter output has recovered, mostly. But demand is still way above supply.
It's server thrashing time.

---

Grant
Darwin NT

Wow.
Just under 210k.

And looks like the Assimilators are staring to have problems keeping up with that sustained load.

---

Grant
Darwin NT

221k now.

Looking at my transfers the upload server is struggling at times as well.

---

Kevin

221k now.

Make that 233k.
And the splitter output is diving, along with the Ready-to-send buffer.
If the load doesn't taper off soon, it's all going to come to a grinding halt till the returned work load drops off significantly and the backlogs clear.
A big batch of Arecibo VLARs & AP work would be helpful right about now.

Looking at my transfers the upload server is struggling at times as well.

I've noticed a few downloads taking a while to get going.

---

Grant
Darwin NT

Hey - I have noticed many WUs recently that process in < 10 secs. Like dozens or hundreds/day, both on GPU and CPU. Are these the "noisy" WUs referred to above? Are they the variety that has 30 spikes detected and then dropped by the app(s)?

---

Wowie Zowie !!!

Results Returned in Last Hour has hit 237,593 and the RTS is practically empty (30K). The system is still up though. It is 7am in California, so hopefully soon someone will notice and throw us an Aricebo dataset , if they have one.