Please help me find out if this problem is my computer,
or with the seti@home website.

Everything was working fine before the Jan. 21 maintenance downtime.
I have not been able to receive any tasks since.

The messages i get when trying to update are:
- Project communication failed: attempting access to reference site
- Internet access OK - project servers may be temporarily down.

thats all i see regarding this problem.

Also i dont know if this matters, but since the problem started,
i did remove my app_info.xml figuring it would renew with my website
options i have set but it hasnt been downloaded yet since i havent
got any new tasks yet since the 21st.

i am not sure if this is a seti@home issue or if i will need to re-install
my boinc and seti@home....

suggestions please.
thanks in advance.

---

• win7starter
  
• boinc: 7.14.2
  
• boinc tasks: 1.78
  
• Lunatics Win32 v0.44
  

If it is not an exponential average, then it must be an average of some fixed time period.

Ville what you see on the SSP is just a snapshot that is taken at the time and nothing else and that could change a lot a few seconds later. ;-)

There is no such thing as instantaneous snapshot of the rate of discrete events. The rate of something is the time derivative of the amount of this something. For the instantaneous rate to exist this amount must be differentiable. The amount here is the number of tasks produced, which is an integer. A non constant integer valued function is not differentiable, so it's a mathematical impossibility for the instantaneous rate does to exist.

It must be the average rate over some time period. I don't know what this time period is but because the value is not an integer, it must be longer than a second. Using the time between two ssp updates would be the simplest way to implement it and would also give more useful information than some shorter period.

If it is a fixed period shorter than 10000 seconds, then this period can be deduced from a sufficiently large number of values the rate can take. Can anyone scraping the ssp data provide me some history of the result creation rate values? As numbers, not a graph.

If you can use rrd here it is:
https://transfer.kiska.pw/n2FN6/setiathomev8_creation-creation-g.rrd

@xpozd

Please help me find out if this problem is my computer,
or with the seti@home website.

The website is struggling to meet demand right now

Also i dont know if this matters, but since the problem started,
i did remove my app_info.xml

Put it back, you'll need it. app_info isn't provided by the S@H website; it was created by the Lunatics installer you presumably ran. You'll need it to get the right apps running, or leave it off and the website will give you "stock" apps.

---

Still, as Keith has also observed, sometimes you get more than 200 tasks in one scheduler call.

24-Jan-2020 02:31:58 [SETI@home] Scheduler request completed: got 306 new tasks

The most i have ever seen on my systems is 104.

---

Grant
Darwin NT

If you can use rrd here it is:
https://transfer.kiska.pw/n2FN6/setiathomev8_creation-creation-g.rrd

That rrd file doesn't contain the 'pure' original values but instead averages of more than one value so it is (nearly) impossible to determine the original values to the last decimal position :(

---

I guess the numbers on the server status page are wrong. 'Results waiting for db purging' is zero but I have almost 8000 task in 'Valid' state where they should be included in that zero count.

'Results waiting for db purging' is presently over 4 million.

Also 'results out in the field' dropped suspiciously fast and

That's what happens when systems are low on caches, the splitters stop splitting, the return rate is almost double it's usual levels, and people are able to get work.
Nothing suspicious about it at all.

Astropulse results out is only 71

No, that is presently almost 92 thousand.[/quote]

---

Grant
Darwin NT

Woke up to find both of my systems out of GPU work, and almost out of CPU work.

---

Grant
Darwin NT

Still, as Keith has also observed, sometimes you get more than 200 tasks in one scheduler call.

24-Jan-2020 02:31:58 [SETI@home] Scheduler request completed: got 306 new tasks

Well it looks like by that that the feeder capacity has been doubled again (400?).

Cheers.

Still, as Keith has also observed, sometimes you get more than 200 tasks in one scheduler call.

24-Jan-2020 02:31:58 [SETI@home] Scheduler request completed: got 306 new tasks

Well it looks like by that that the feeder capacity has been doubled again (400?).

Or have they doubled the number of feeders?
Unlikely as getting work has still been near impossible much of the time, even when there was some work to get.

---

Grant
Darwin NT

Still, as Keith has also observed, sometimes you get more than 200 tasks in one scheduler call.

24-Jan-2020 02:31:58 [SETI@home] Scheduler request completed: got 306 new tasks

Well it looks like by that that the feeder capacity has been doubled again (400?).

Cheers.

No, that wouldn't be the case as I have routinely seen more than 200 tasks in a download long before the cache levels were adjusted. Like for years.

---

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

A proud member of the OFA (Old Farts Association)

Looks like the splitters have been enabled again. I got some work on a host. Looks like 44 tasks.

---

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

A proud member of the OFA (Old Farts Association)

Unlikely as getting work has still been near impossible much of the time, even when there was some work to get.

And I doubt that things will improve while all these blc35 noise bombs are being spewed out. :-(

Cheers.

It would help things no end if they pulled all the BLC35 files until things have settled down- they'd have to be 95%+ noise bombs Allow people's caches to fill, reduce the return rate and let the servers clear up all the backlogs.

Once the servers have settled down, they've tweaked things to suit the new database arrangement, then reload the BLC35s to stress test the system then.

---

Grant
Darwin NT

Unlikely as getting work has still been near impossible much of the time, even when there was some work to get.

And I doubt that things will improve while all these blc35 noise bombs are being spewed out. :-(

Yep.
Looking at the graphs, the return rate got to just over 200k, and then the system just fell over.

---

Grant
Darwin NT

Astropulse results out is only 71

No, that is presently almost 92 thousand.

Looks like the data is sane again. AP out in the field was 71, S@H v8 out in the field was about 30000 and results ready to send for v8 was around 30k too and these values stayed exactly the same for about an hour or more despite the page timestamp updating every 10 min and 'as of' column staying in single digit minutes.

---

Looks like the data is sane again. AP out in the field was 71, S@H v8 out in the field was about 30000 and results ready to send for v8 was around 30k too and these values stayed exactly the same for about an hour or more despite the page timestamp updating every 10 min and 'as of' column staying in single digit minutes.

The graphs show a roughly 2 hour period several hours after the system crashed where there was no data, or it was the wrong data, being returned.

---

Grant
Darwin NT

And the splitters are disabled again.

---

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

A proud member of the OFA (Old Farts Association)

If you can use rrd here it is:
https://transfer.kiska.pw/n2FN6/setiathomev8_creation-creation-g.rrd

I couldn't get exact match because of the averaged noise in the data but the window size that matched the most samples was 299 seconds. Multiples of 299 matched a little bit more but so little that it was just by chance. 149.5 (half of 299) matched about half the number of samples compared to 299 and quarter of 299 about quarter the number of samples. These
are the expected results if 299 is the true value.

---

And the splitters are disabled again.

Worse than that- Not running.
At least if they were disabled ti would mean someone has disabled them (hopefully to sort something out). Not running, when needed, indicates they're just broken.

I think they've got a bit more work to do on their reorganisation yet before they can declare it done & ready to go.

---

Grant
Darwin NT

Or have they doubled the number of feeders?

No, the whole point of the feeder system is to keep a single list of tasks in shared memory to avoid duplicate allocations. Even if there were multiple feeders, they'd still have to work off a common list.