RTS to zero. Splitters not able to keep up with demand. I at least was able to fill my caches up before the well ran dry. That should last for about an hour. I think we have finally cleaned the majority of the noise bombs out at least.

---

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

A proud member of the OFA (Old Farts Association)

The results in the field amount has been slowly climbing, so I think that the splitters are doing better than demand, but it will take a while to fill up all the caches, and then hopefully the RTS will start to fill. It isn't just current demand that needs to be met, but the backlog because it had shut down for a while. I guess like after a outage.
Hopefully all will be back to "normal" be before Tuesday's outrage in a few hours.

Looks as though it died again. RTS Empty, Splitters at 5.x. Computers getting No Tasks again.
It's going to a long night.

Looks as though it died again. RTS Empty, Splitters at 5.x. Computers getting No Tasks again.
It's going to a long night.

I agree :-( . Not good news before the Tuesday outage

Nice Kick! Suddenly I'm getting work again.

About the same on two machines;

Tue Sep 4 01:08:26 2018 | SETI@home | Sending scheduler request: To report completed tasks.
Tue Sep 4 01:08:26 2018 | SETI@home | Reporting 11 completed tasks
Tue Sep 4 01:08:28 2018 | SETI@home | Scheduler request completed: got 71 new tasks

The page still hasn't updated for 50 minutes, but I got work.

I see that the splitters still have not filled the RTS cache.
I would be expecting a long outage today to sort things.

Meow.

---

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

we back??

---

we back??

Status page says no, but that might update soon

we back??

Status page says no, but that might update soon

. . I've gotten work on 3 of the 4 crunchers, but mostly still those noisy Blc11 WUs. It is evaporating almost as quickly as it can download ... :(

. . It's going to be a while before I have stable caches for the rigs to keep working productively ...

Stephen

:(

{Edit} Work availability is surprisingly high for post outage. My caches are filling up. I would still feel better if there were not so many of the Blc11 tasks in the mix.

.

Hope someone can help diagnose this server connection issue.
Tue 04 Sep 2018 05:58:26 PM PDT | SETI@home | Sending scheduler request: Requested by user.
Tue 04 Sep 2018 05:58:26 PM PDT | SETI@home | Reporting 100 completed tasks
Tue 04 Sep 2018 05:58:26 PM PDT | SETI@home | Requesting new tasks for CPU and NVIDIA GPU
Tue 04 Sep 2018 05:58:26 PM PDT | SETI@home | [sched_op] CPU work request: 714052.70 seconds; 0.00 devices
Tue 04 Sep 2018 05:58:26 PM PDT | SETI@home | [sched_op] NVIDIA GPU work request: 349056.00 seconds; 4.00 devices
Tue 04 Sep 2018 05:58:26 PM PDT | SETI@home | [http] HTTP_OP::init_post(): http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
Tue 04 Sep 2018 05:58:26 PM PDT | SETI@home | [http] [ID#1] Info: Hostname in DNS cache was stale, zapped
Tue 04 Sep 2018 05:58:26 PM PDT | SETI@home | [http] [ID#1] Info: Trying 192.168.1.254...
Tue 04 Sep 2018 05:58:26 PM PDT | SETI@home | [http] [ID#1] Info: TCP_NODELAY set
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Info: Connected to setiboinc.ssl.berkeley.edu (192.168.1.254) port 80 (#7)
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Sent header to server: POST /sah_cgi/cgi HTTP/1.1
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Sent header to server: Host: setiboinc.ssl.berkeley.edu
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Sent header to server: User-Agent: BOINC client (x86_64-pc-linux-gnu 7.4.44)
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Sent header to server: Accept: */*
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Sent header to server: Accept-Encoding: deflate, gzip
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Sent header to server: Content-Type: application/x-www-form-urlencoded
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Sent header to server: Accept-Language: en_US
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Sent header to server: Content-Length: 560366
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Sent header to server: Expect: 100-continue
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Sent header to server:
Tue 04 Sep 2018 05:58:28 PM PDT | SETI@home | [http] [ID#1] Info: Done waiting for 100-continue
Tue 04 Sep 2018 05:58:29 PM PDT | SETI@home | [http] [ID#1] Info: We are completely uploaded and fine
Tue 04 Sep 2018 05:58:29 PM PDT | SETI@home | [http] [ID#1] Received header from server: HTTP/1.1 200 OK
Tue 04 Sep 2018 05:58:29 PM PDT | SETI@home | [http] [ID#1] Received header from server: Connection: close
Tue 04 Sep 2018 05:58:29 PM PDT | SETI@home | [http] [ID#1] Received header from server: PANIC: unprotected error in call to Lua API (haserl_lualib.lua:34: attempt to index local 't' (a string value))
Tue 04 Sep 2018 05:58:30 PM PDT | SETI@home | [http] [ID#1] Info: Closing connection 7
Tue 04 Sep 2018 05:58:30 PM PDT | SETI@home | [error] No start tag in scheduler reply
Tue 04 Sep 2018 05:58:30 PM PDT | SETI@home | [sched_op] Deferring communication for 02:01:13
Tue 04 Sep 2018 05:58:30 PM PDT | SETI@home | [sched_op] Reason: can't parse scheduler reply

---

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

A proud member of the OFA (Old Farts Association)

I have always used the static DNS entries, and they seem to be working fine.

That machine eventually found the servers home. Just two machines managed to get some work just at project return when I beat out all others for the dwindling tasks in the buffer. The other 3 machines have struck out so far tonight in snagging any work.

---

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

A proud member of the OFA (Old Farts Association)

good news... they loaded more data files to be split...

The new blc16 is from the same day (58227) as the data bomb blc11 files. Is that a problem?? what does the number after the blc denote??

good news... they loaded more data files to be split...
The new blc16 is from the same day (58227) as the data bomb blc11 files. Is that a problem?? what does the number after the blc denote??

Not so good news ... I just ran a sample 19 BLC16 tasks through ... 9 were not noise.

So we have a LOT more of this crap now :(

Hope someone can help diagnose this server connection issue.
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Info: Connected to setiboinc.ssl.berkeley.edu (192.168.1.254) port 80 (#7)

$ping setiboinc.ssl.berkeley.edu
PING setiboinc.ssl.berkeley.edu (208.68.240.126): 56 data bytes

I ran another 32 blc16 tasks ... 13 good ones.
"Captain, How to you expect warp speed when all we have to feed the hamsters is tofu!"

Splitters still having problems getting their act together; they get going, but struggle to maintain that output.

---

Grant
Darwin NT

Hope someone can help diagnose this server connection issue.
Tue 04 Sep 2018 05:58:27 PM PDT | SETI@home | [http] [ID#1] Info: Connected to setiboinc.ssl.berkeley.edu (192.168.1.254) port 80 (#7)

All IP addresses in the 192.168.xxx.yyy range are for private use on internal networks only, and can't be routed over the internet.

I would guess that 192.168.1.254 is the address of Keith's home router, acting as a DHCP server allocating other IP addresses to the machines on the local network in his home. I'd expect it's also acting as his gateway to the outside world, and perhaps even as DNS server resolving server names into IP addresses.

My equivalent, using the Windows command 'ipconfig /all' (Linux will have something similar), is 192.168.173.1:

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : home
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : FC-AA-14-CB-13-17
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::19ef:5e13:18be:e3b0%11(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.173.26(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 01 September 2018 08:35:13
   Lease Expires . . . . . . . . . . : 06 September 2018 08:35:26
   Default Gateway . . . . . . . . . : 192.168.173.1
   DHCP Server . . . . . . . . . . . : 192.168.173.1
   DHCPv6 IAID . . . . . . . . . . . : 251439636
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-27-44-01-FC-AA-14-CB-13-17

   DNS Servers . . . . . . . . . . . : 192.168.173.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

My guess is that there was a glitch on the local connection from Keith's router to his ISP. The router saw the port 80 request and couldn't handle it because of the glitch. The router assumed it came from a web browser, and sent back a user-friendly error message to explain what had gone wrong. Mine does that, too:


Unfortunately, BOINC doesn't know how to handle error messages when it's expecting a reply from the project server...

Thanks again Jord, your trick to get a stuck upload to go through worked again :)
My Ryzen has had one stuck for 3 days, wouldn't upload or abort.

It took me a bit to find the reference info from a year ago.
https://setiathome.berkeley.edu/forum_thread.php?id=82054&postid=1895643

good news... they loaded more data files to be split...

The new blc16 is from the same day (58227) as the data bomb blc11 files. Is that a problem?? what does the number after the blc denote??

. . the channel/frequency band being split from the receiver. There are lots of recorders, seems to be blc0x, blc1x to I suspect blc7x if/when they are installed. Highest I have seen to date was blc2x if memory serves me. And they are blcn0-7.

Stephen

. .