If you're only reporting or requesting work you get through (though I've yet to get any new work), but if you do both at the same time you get the HTTP error response.

Other than that the SSP updates the page time yet the other numbers don't seem to be changing at all.

Cheers.

I can't get any CPU tasks which I really need. I'm OK on GPUs.

---

If you're only reporting or requesting work you get through (though I've yet to get any new work), but if you do both at the same time you get the HTTP error response.

Other than that the SSP updates the page time yet the other numbers don't seem to be changing at all.

Cheers.

That worked selecting NNT, strange.

If you're only reporting or requesting work you get through (though I've yet to get any new work), but if you do both at the same time you get the HTTP error response.

Looks like I've managed to get one MB and ten APV7 tasks tonight (all AP tasks on my work laptop).

Other than that the SSP updates the page time yet the other numbers don't seem to be changing at all.

Seems to be some problems with the database, e.g. I get no response when I try to look at my Errors page to see if there are any new errors.

---

If you're only reporting or requesting work you get through (though I've yet to get any new work), but if you do both at the same time you get the HTTP error response.

Looks like I've managed to get one MB and ten APV7 tasks tonight (all AP tasks on my work laptop).

Other than that the SSP updates the page time yet the other numbers don't seem to be changing at all.

Seems to be some problems with the database, e.g. I get no response when I try to look at my Errors page to see if there are any new errors.

And I have newly-reported work where both quorum copies are present, but the validators haven't looked at them yet.

Feels like the same as last week, and occasionally after previous outages.

It seems to take a long time for the database engine to restart - whether it's loading tables into memory, integrity-checking the indexes, or something else, I don't know. But after a few hours, it lets out an almighty sneeze, and suddenly everything works at full speed again.

It seems to take a long time for the database engine to restart - whether it's loading tables into memory, integrity-checking the indexes, or something else, I don't know. But after a few hours, it lets out an almighty sneeze, and suddenly everything works at full speed again.

Yeah, response is suddenly back to normal now, database queries are up, and reported delays are more like usual.

---

I also tried setting NNT to report, and the machine reported 200+ tasks (Yay!!!) but I also got this message:

10/28/2014 7:59:45 PM | SETI@home | Not requesting tasks: scheduler RPC backoff

what does THAT mean?

Thanks!

---

Yep, about the same. Only this time both my Linux & Windows Machines are working, it's the Mac that keeps getting the HTTP error. I was already up to 15 Ready to reports again since they were reported earlier. I set it to No New Tasks and they all cleared. The next Report I was sent 6 AP Resends...all at once. Yep, they all went to the CPUs even though my GPUs are down to just 36 tasks left.

Tue Oct 28 19:48:07 2014 | SETI@home | Requesting new tasks for CPU and ATI
Tue Oct 28 19:48:09 2014 | SETI@home | Scheduler request completed: got 6 new tasks
Tue Oct 28 19:48:11 2014 | SETI@home | Started download of ap_05mr11ac_B1_P1_00183_20141009_11417.wu
...

http://setiathome.berkeley.edu/results.php?hostid=6796479

Oh well, it's back to the HTTP errors again.

10/28/2014 7:59:45 PM | SETI@home | Not requesting tasks: scheduler RPC backoff

what does THAT mean?

After BOINC contacted the server, the server tells BOINC to back off for 5 minutes and 3 seconds. If you or something else tries to get BOINC to contact the server in that back-off time, you get that message. It's there so not to DDoS the server.

You can also have this message when you're in a longer back-off period. You can see that by opening BOINC Manager -> advanced view -> Projects tab -> select Seti@Home -> Properties. All the back-off periods are shown here.

You can try to have BOINC communicate with the server before the end of such a longer back-off period by going Advanced->Do network communication. This only works on the longer back-off periods, not on the 5 minutes and 3 second back-off you get from the server after having had database contact.

---

I received a few vlars for my Nvidia GPUs. Anyone else???

Hope this isn't something new and the battle to keep Vlars off of Nvidia cards has to be fought again.

---

This is all I have been getting for many hours, not good. As nearly as I can tell I'm asking for AP6, AP7 and MB7, so I'll take anything.
1

0/28/2014 7:06:16 PM | SETI@home | Sending scheduler request: Requested by user.
10/28/2014 7:06:16 PM | SETI@home | Reporting 1 completed tasks
10/28/2014 7:06:16 PM | SETI@home | Requesting new tasks for CPU
10/28/2014 7:06:58 PM | SETI@home | Scheduler request completed: got 0 new tasks
10/28/2014 7:06:58 PM | SETI@home | Project has no tasks available

---

Well I finally got a few MBs so the CPU has something to do.

---

After having a little nap I found that neither of my rigs ran out of GPU work and both have been rebuilding their caches.

Cheers.

your nap fixed the server

Been running a handful of seti cpu tasks. I have no problem if I run out. My second project has a data set running. So far it has 120 hours running and another 300 hours to complete. If seti ever runs dry on work here? My other project will plug the gap.

---

Back on the cache limits again and without hitting up a backup project this week.

Cheers.

10/28/2014 7:59:45 PM | SETI@home | Not requesting tasks: scheduler RPC backoff

what does THAT mean?

After BOINC contacted the server, the server tells BOINC to back off for 5 minutes and 3 seconds. If you or something else tries to get BOINC to contact the server in that back-off time, you get that message. It's there so not to DDoS the server.

You can also have this message when you're in a longer back-off period. You can see that by opening BOINC Manager -> advanced view -> Projects tab -> select Seti@Home -> Properties. All the back-off periods are shown here.

You can try to have BOINC communicate with the server before the end of such a longer back-off period by going Advanced->Do network communication. This only works on the longer back-off periods, not on the 5 minutes and 3 second back-off you get from the server after having had database contact.

I know about the 5 minute backoff; I had just never seen the RPC in the message before. I assume that is a Windows Remote Program/Process Call reference(?).
(Sorry I didn't make myself clear in the original post)

---

10/28/2014 7:59:45 PM | SETI@home | Not requesting tasks: scheduler RPC backoff

what does THAT mean?

After BOINC contacted the server, the server tells BOINC to back off for 5 minutes and 3 seconds. If you or something else tries to get BOINC to contact the server in that back-off time, you get that message. It's there so not to DDoS the server.

You can also have this message when you're in a longer back-off period. You can see that by opening BOINC Manager -> advanced view -> Projects tab -> select Seti@Home -> Properties. All the back-off periods are shown here.

You can try to have BOINC communicate with the server before the end of such a longer back-off period by going Advanced->Do network communication. This only works on the longer back-off periods, not on the 5 minutes and 3 second back-off you get from the server after having had database contact.

I know about the 5 minute backoff; I had just never seen the RPC in the message before. I assume that is a Windows Remote Program/Process Call reference(?).
(Sorry I didn't make myself clear in the original post)

Remote Procedure Call

Although Windows will have an implementation, it's a generic tool, and you would see the same message in Linux and OS X too.

I'll be reporting my 3 baby's here later on...

---

rOZZ
Music
Pictures

Having problems reporting and requesting, get

29/10/2014 21:48:50 | SETI@home | Scheduler request failed: HTTP internal server error