Add me to the list. Uploads OK. Reports not.

Mike

Tim,

One pc is Vista 64 bit (CPU only), the other one XP 32 bit (CPU and GPU). Both are currently running other projects without any problem. Other pc's (both Linux 64 bit and XP 32 bit) have reported similar amounts of tasks using the same router/modem.

I am now trying to activate the log_flags to see what happens during the reporting cycle.

Ah ok guys did not realise it had been going on from before last outage period

so yes must be something outside your control and your pc as reporting ok for other projects

very odd

is it all you S@NL team thats affected or just the unlucky ones

---

Tim

This is the debug output from the XP machine:

31-07-10 12:19:54	SETI@home	update requested by user
31-07-10 12:19:58	SETI@home	[sched_op_debug] Starting scheduler request
31-07-10 12:19:58	SETI@home	Sending scheduler request: Requested by user.
31-07-10 12:19:58	SETI@home	Reporting 347 completed tasks, requesting new tasks for CPU and GPU
31-07-10 12:19:58	SETI@home	[sched_op_debug] CPU work request: 2747162.36 seconds; 4.00 CPUs
31-07-10 12:19:58	SETI@home	[sched_op_debug] NVIDIA GPU work request: 680893.39 seconds; 1.00 GPUs
31-07-10 12:19:58		[http_debug] HTTP_OP::init_post(): http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
31-07-10 12:19:58		[http_debug] HTTP_OP::libcurl_exec(): ca-bundle 'C:\Program Files\BOINC\ca-bundle.crt'
31-07-10 12:19:58		[http_debug] HTTP_OP::libcurl_exec(): ca-bundle set
31-07-10 12:19:59		[http_debug] [ID#1] Info:  timeout on name lookup is not supported
31-07-10 12:19:59		[http_debug] [ID#1] Info:  About to connect() to setiboinc.ssl.berkeley.edu port 80 (#0)
31-07-10 12:19:59		[http_debug] [ID#1] Info:    Trying 208.68.240.20... 
31-07-10 12:20:20		[http_debug] [ID#1] Info:  Timed out
31-07-10 12:20:20		[http_debug] [ID#1] Info:  Failed connect to setiboinc.ssl.berkeley.edu:80; No error
31-07-10 12:20:20		[http_debug] [ID#1] Info:  Expire cleared
31-07-10 12:20:20		[http_debug] [ID#1] Info:  Closing connection #0
31-07-10 12:20:20		[http_debug] HTTP error: Couldn't connect to server

I can ping 208.68.240.20 without any problem

And here's the debug output when there is a HTTP internal server error:

31-07-10 12:29:36	SETI@home	update requested by user
31-07-10 12:29:41	SETI@home	[sched_op_debug] Starting scheduler request
31-07-10 12:29:41	SETI@home	Sending scheduler request: Requested by user.
31-07-10 12:29:41	SETI@home	Reporting 347 completed tasks, requesting new tasks for CPU and GPU
31-07-10 12:29:41	SETI@home	[sched_op_debug] CPU work request: 2749849.83 seconds; 4.00 CPUs
31-07-10 12:29:41	SETI@home	[sched_op_debug] NVIDIA GPU work request: 681493.71 seconds; 1.00 GPUs
31-07-10 12:29:41		[http_debug] HTTP_OP::init_post(): http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
31-07-10 12:29:41		[http_debug] HTTP_OP::libcurl_exec(): ca-bundle set
31-07-10 12:29:42		[http_debug] [ID#1] Info:  Connection #0 seems to be dead!
31-07-10 12:29:42		[http_debug] [ID#1] Info:  Closing connection #0
31-07-10 12:29:42		[http_debug] [ID#1] Info:  Connection #1 seems to be dead!
31-07-10 12:29:42		[http_debug] [ID#1] Info:  Closing connection #1
31-07-10 12:29:42		[http_debug] [ID#1] Info:  Connection #2 seems to be dead!
31-07-10 12:29:42		[http_debug] [ID#1] Info:  Closing connection #2
31-07-10 12:29:42		[http_debug] [ID#1] Info:  Connection #3 seems to be dead!
31-07-10 12:29:42		[http_debug] [ID#1] Info:  Closing connection #3
31-07-10 12:29:42		[http_debug] [ID#1] Info:  timeout on name lookup is not supported
31-07-10 12:29:42		[http_debug] [ID#1] Info:  About to connect() to setiboinc.ssl.berkeley.edu port 80 (#0)
31-07-10 12:29:42		[http_debug] [ID#1] Info:    Trying 208.68.240.20... 
31-07-10 12:29:42		[http_debug] [ID#1] Info:  Connected to setiboinc.ssl.berkeley.edu (208.68.240.20) port 80 (#0)
31-07-10 12:29:42		[http_debug] [ID#1] Sent header to server: POST /sah_cgi/cgi HTTP/1.1

31-07-10 12:29:42		[http_debug] [ID#1] Sent header to server: User-Agent: BOINC client (windows_intelx86 6.10.58)

31-07-10 12:29:42		[http_debug] [ID#1] Sent header to server: Host: setiboinc.ssl.berkeley.edu

31-07-10 12:29:42		[http_debug] [ID#1] Sent header to server: Accept: */*

31-07-10 12:29:42		[http_debug] [ID#1] Sent header to server: Accept-Encoding: deflate, gzip

31-07-10 12:29:42		[http_debug] [ID#1] Sent header to server: Content-Type: application/x-www-form-urlencoded

31-07-10 12:29:42		[http_debug] [ID#1] Sent header to server: Content-Length: 1002135

31-07-10 12:29:42		[http_debug] [ID#1] Sent header to server: Expect: 100-continue

31-07-10 12:29:42		[http_debug] [ID#1] Sent header to server: 

31-07-10 12:29:43		[http_debug] [ID#1] Info:  Done waiting for 100-continue
31-07-10 12:29:45		[http_debug] [ID#1] Received header from server: HTTP/1.1 100 Continue

31-07-10 12:30:29		[http_debug] [ID#1] Received header from server: HTTP/1.1 500 Internal Server Error

31-07-10 12:30:29		[http_debug] [ID#1] Received header from server: Date: Sat, 31 Jul 2010 10:30:03 GMT

31-07-10 12:30:29		[http_debug] [ID#1] Received header from server: Server: Apache/2.2.15 (Fedora)

31-07-10 12:30:29		[http_debug] [ID#1] Received header from server: Content-Length: 637

31-07-10 12:30:29		[http_debug] [ID#1] Received header from server: Connection: close

31-07-10 12:30:29		[http_debug] [ID#1] Received header from server: Content-Type: text/html; charset=iso-8859-1

31-07-10 12:30:29		[http_debug] [ID#1] Received header from server: 

31-07-10 12:30:29		[http_xfer_debug] [ID#1] HTTP: wrote 637 bytes
31-07-10 12:30:29		[http_debug] [ID#1] Info:  Expire cleared
31-07-10 12:30:29		[http_debug] [ID#1] Info:  Closing connection #0
31-07-10 12:30:30	SETI@home	Scheduler request failed: HTTP internal server error

I assume that the time-out error (scheduler request failed: Couldn't connect to server) are caused by the load on the scheduling server, but the internal server error should not occur.

This is the debug output from the XP machine:


31-07-10 12:19:54 SETI@home update requested by user
31-07-10 12:19:58 SETI@home [sched_op_debug] Starting scheduler request
31-07-10 12:19:58 SETI@home Sending scheduler request: Requested by user.
31-07-10 12:19:58 SETI@home Reporting 347 completed tasks, requesting new tasks for CPU and GPU
31-07-10 12:19:58 SETI@home [sched_op_debug] CPU work request: 2747162.36 seconds; 4.00 CPUs
31-07-10 12:19:58 SETI@home [sched_op_debug] NVIDIA GPU work request: 680893.39 seconds; 1.00 GPUs
31-07-10 12:19:58 [http_debug] HTTP_OP::init_post(): http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
31-07-10 12:19:58 [http_debug] HTTP_OP::libcurl_exec(): ca-bundle 'C:\Program Files\BOINC\ca-bundle.crt'
31-07-10 12:19:58 [http_debug] HTTP_OP::libcurl_exec(): ca-bundle set
31-07-10 12:19:59 [http_debug] [ID#1] Info: timeout on name lookup is not supported
31-07-10 12:19:59 [http_debug] [ID#1] Info: About to connect() to setiboinc.ssl.berkeley.edu port 80 (#0)
31-07-10 12:19:59 [http_debug] [ID#1] Info: Trying 208.68.240.20...
31-07-10 12:20:20 [http_debug] [ID#1] Info: Timed out
31-07-10 12:20:20 [http_debug] [ID#1] Info: Failed connect to setiboinc.ssl.berkeley.edu:80; No error
31-07-10 12:20:20 [http_debug] [ID#1] Info: Expire cleared
31-07-10 12:20:20 [http_debug] [ID#1] Info: Closing connection #0
31-07-10 12:20:20 [http_debug] HTTP error: Couldn't connect to server

I can ping 208.68.240.20 without any problem

In bold above is the only slight difference i get on a failed report - basically i do not get that line - i assume your crt file is actually there

when it works you get the following sort of trace

31/07/2010 11:48:59	SETI@home	update requested by user
31/07/2010 11:49:02	SETI@home	[sched_op_debug] Starting scheduler request
31/07/2010 11:49:02	SETI@home	Sending scheduler request: Requested by user.
31/07/2010 11:49:02	SETI@home	Reporting 5 completed tasks, not requesting new tasks
31/07/2010 11:49:02	SETI@home	[sched_op_debug] CPU work request: 0.00 seconds; 0.00 CPUs
31/07/2010 11:49:02	SETI@home	[sched_op_debug] NVIDIA GPU work request: 0.00 seconds; 0.00 GPUs
31/07/2010 11:49:02		[http_debug] HTTP_OP::init_post(): http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
31/07/2010 11:49:02		[http_debug] HTTP_OP::libcurl_exec(): ca-bundle set
31/07/2010 11:49:02		[http_debug] [ID#1] Info:  timeout on name lookup is not supported
31/07/2010 11:49:02		[http_debug] [ID#1] Info:  About to connect() to setiboinc.ssl.berkeley.edu port 80 (#2)
31/07/2010 11:49:02		[http_debug] [ID#1] Info:    Trying 208.68.240.20... 
31/07/2010 11:49:05		[http_debug] [ID#1] Info:  Connected to setiboinc.ssl.berkeley.edu (208.68.240.20) port 80 (#2)
31/07/2010 11:49:05		[http_debug] [ID#1] Sent header to server: POST /sah_cgi/cgi HTTP/1.1
31/07/2010 11:49:05		[http_debug] [ID#1] Sent header to server: User-Agent: BOINC client (windows_x86_64 6.10.58)
31/07/2010 11:49:05		[http_debug] [ID#1] Sent header to server: Host: setiboinc.ssl.berkeley.edu
31/07/2010 11:49:05		[http_debug] [ID#1] Sent header to server: Accept: */*
31/07/2010 11:49:05		[http_debug] [ID#1] Sent header to server: Accept-Encoding: deflate, gzip
31/07/2010 11:49:05		[http_debug] [ID#1] Sent header to server: Content-Type: application/x-www-form-urlencoded
31/07/2010 11:49:05		[http_debug] [ID#1] Sent header to server: Content-Length: 143162
31/07/2010 11:49:05		[http_debug] [ID#1] Sent header to server: Expect: 100-continue
31/07/2010 11:49:05		[http_debug] [ID#1] Sent header to server: 
31/07/2010 11:49:07		[http_debug] [ID#1] Info:  Done waiting for 100-continue
31/07/2010 11:49:21		[http_debug] [ID#1] Received header from server: HTTP/1.1 100 Continue
31/07/2010 11:49:23		[http_debug] [ID#1] Received header from server: HTTP/1.1 200 OK
31/07/2010 11:49:23		[http_debug] [ID#1] Received header from server: Date: Sat, 31 Jul 2010 10:49:22 GMT
31/07/2010 11:49:23		[http_debug] [ID#1] Received header from server: Server: Apache/2.2.15 (Fedora)
31/07/2010 11:49:23		[http_debug] [ID#1] Received header from server: Connection: close
31/07/2010 11:49:23		[http_debug] [ID#1] Received header from server: Transfer-Encoding: chunked
31/07/2010 11:49:23		[http_debug] [ID#1] Received header from server: Content-Type: text/xml
31/07/2010 11:49:23		[http_debug] [ID#1] Received header from server: 
31/07/2010 11:49:23		[http_xfer_debug] [ID#1] HTTP: wrote 3307 bytes
31/07/2010 11:49:23		[http_xfer_debug] [ID#1] HTTP: wrote 1712 bytes
31/07/2010 11:49:23		[http_debug] [ID#1] Info:  Expire cleared
31/07/2010 11:49:23		[http_debug] [ID#1] Info:  Closing connection #2
31/07/2010 11:49:23	SETI@home	Scheduler request completed

just seen your latest post

have you tried turning off the work request for seti - bit of a wild guess probably has not effect

---

Tim

When I set Seti to No New Tasks, I get the same HTTP internal server error. With NNT, I don't get the HTTP_OP::libcurl_exec(): ca-bundle 'C:\Program Files\BOINC\ca-bundle.crt' so those are probably related.

Edit:
The certificate file is there, and I could not find any differences with the same file on a reporting pc.

Do you have any anti virus / firewall software running?

as dead network connections for four different nic's might be a clue

---

Tim

Mine have reported at last!

Mike

Do you have any anti virus / firewall software running?

as dead network connections for four different nic's might be a clue

Anti virus and firewall are off. There is only 1 nic per pc and I think that the "dead connection" message only means that a particular outgoing connection is not usable at that time.

When there is a message like:

31-07-10 13:52:02		[http_debug] [ID#1] Info:  Connection #2 seems to be dead!

And I scroll back a few lines, I see this:

31-07-10 13:50:56		[http_debug] [ID#1] Info:  Connection #2 to host boinc.gorlaeus.net left intact

The problem of not being able to report started on 26 of July.
That is true for Ronald, OfficeDude, John van Gorsel and me.
Same problem is also reported by others on our forum of SETI@Netherlands.

Which ISP are you using? Are all of you using the same ISP?
Did something change at the ISP, increased/decreased bandwidth, changed from copper to fibre, things like that?

---

boinc.gorlaeus.net

That's the Leiden Classical project. Is you BOINC trying to do a scheduler contact with this project?

---

John

not sure about the dead connection as mine only ever shows #2 - could be wrong but i only have one nic also but its call #2 as i changed cards (well motherboard) without re installing windows - have you had other nic's in the pc before - if not ignore what i said

other than the isp idea from ageless - could be the answer if seti uses a different connection method to other boinc projects which on the same pc and isp are working ok - i would have thought boinc would use the same for all to keep things standard but could also be wrong

other than deleting the nic out of windows and reinstall bm after a reboot with refreshed nic drivers i have run out of ideas

good luck hope somebody else has a good idea or you figure it out yourself

---

Tim

Don't delete the NIC, that's not necessary. It's a connection problem. Possibly caused by something that changed along the way to Seti, or at the ISP.

For the moment you can try to force BOINC to use the HTTP 1.0 protocol, instead of the HTTP 1.1 protocol. To do so, add into your cc_config.xml file:

<cc_config>
<log_flags>
</log_flags>
<options>
<http_1_0>1</http_1_0>
</options>
</cc_config>

Then load this config file into BOINC by restarting the client. Now try to report again (do keep the other debug flags on).

---

Hmm last 2 days I have log messages:
31.7.2010 15:26:06 SETI@home update requested by user
31.7.2010 15:26:56 Project communication failed: attempting access to reference site
31.7.2010 15:26:56 SETI@home Scheduler request failed: Failure when receiving data from the peer
31.7.2010 15:26:58 Internet access OK - project servers may be temporarily down.

Have a SETI's router or back-servers something problem?

Becouse all another working fine.

Thanks to all crunshers...

boinc.gorlaeus.net

That's the Leiden Classical project. Is you BOINC trying to do a scheduler contact with this project?

No, both my "problem" pc's are now doing Leiden tasks. I just included that line from the log to show that the connection that Seti assumes is "dead" is in fact in use by a different project.

For the moment you can try to force BOINC to use the HTTP 1.0 protocol, instead of the HTTP 1.1 protocol. To do so, add into your cc_config.xml file:

<cc_config>
<log_flags>
</log_flags>
<options>
<http_1_0>1</http_1_0>
</options>
</cc_config>

Then load this config file into BOINC by restarting the client. Now try to report again (do keep the other debug flags on).

Didn't work, although BOINC is sending a header using HTTP 1.0.

Debug info:

31-07-10 15:06:34	SETI@home	[sched_op_debug] Starting scheduler request
31-07-10 15:06:34	SETI@home	Sending scheduler request: To report completed tasks.
31-07-10 15:06:34	SETI@home	Reporting 347 completed tasks, not requesting new tasks
31-07-10 15:06:34	SETI@home	[sched_op_debug] CPU work request: 0.00 seconds; 0.00 CPUs
31-07-10 15:06:34	SETI@home	[sched_op_debug] NVIDIA GPU work request: 0.00 seconds; 0.00 GPUs
31-07-10 15:06:34		[http_debug] HTTP_OP::init_post(): http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
31-07-10 15:06:34		[http_debug] HTTP_OP::libcurl_exec(): ca-bundle set
31-07-10 15:06:35		[http_debug] [ID#1] Info:  timeout on name lookup is not supported
31-07-10 15:06:35		[http_debug] [ID#1] Info:  About to connect() to setiboinc.ssl.berkeley.edu port 80 (#0)
31-07-10 15:06:35		[http_debug] [ID#1] Info:    Trying 208.68.240.20... 
31-07-10 15:06:44		[http_debug] [ID#1] Info:  Connected to setiboinc.ssl.berkeley.edu (208.68.240.20) port 80 (#0)
31-07-10 15:06:44		[http_debug] [ID#1] Sent header to server: POST /sah_cgi/cgi HTTP/1.0

31-07-10 15:06:44		[http_debug] [ID#1] Sent header to server: User-Agent: BOINC client (windows_intelx86 6.10.58)

31-07-10 15:06:44		[http_debug] [ID#1] Sent header to server: Host: setiboinc.ssl.berkeley.edu

31-07-10 15:06:44		[http_debug] [ID#1] Sent header to server: Accept: */*

31-07-10 15:06:44		[http_debug] [ID#1] Sent header to server: Accept-Encoding: deflate, gzip

31-07-10 15:06:44		[http_debug] [ID#1] Sent header to server: Content-Type: application/x-www-form-urlencoded

31-07-10 15:06:44		[http_debug] [ID#1] Sent header to server: Content-Length: 1002111

31-07-10 15:06:44		[http_debug] [ID#1] Sent header to server: 

31-07-10 15:07:12		[http_debug] [ID#1] Received header from server: HTTP/1.1 500 Internal Server Error

31-07-10 15:07:12		[http_debug] [ID#1] Received header from server: Date: Sat, 31 Jul 2010 13:07:03 GMT

31-07-10 15:07:12		[http_debug] [ID#1] Received header from server: Server: Apache/2.2.15 (Fedora)

31-07-10 15:07:12		[http_debug] [ID#1] Received header from server: Content-Length: 637

31-07-10 15:07:12		[http_debug] [ID#1] Received header from server: Connection: close

31-07-10 15:07:12		[http_debug] [ID#1] Received header from server: Content-Type: text/html; charset=iso-8859-1

31-07-10 15:07:12		[http_debug] [ID#1] Received header from server: 

31-07-10 15:07:12		[http_xfer_debug] [ID#1] HTTP: wrote 637 bytes
31-07-10 15:07:12		[http_debug] [ID#1] Info:  Expire cleared
31-07-10 15:07:12		[http_debug] [ID#1] Info:  Closing connection #0
31-07-10 15:07:12	SETI@home	Scheduler request failed: HTTP internal server error
31-07-10 15:07:12	SETI@home	[sched_op_debug] Deferring communication for 1 min 0 sec
31-07-10 15:07:12	SETI@home	[sched_op_debug] Reason: Scheduler request failed

Which ISP are you using? Are all of you using the same ISP?
Did something change at the ISP, increased/decreased bandwidth, changed from copper to fibre, things like that?

I'm using KPN ADSL and the last change was made in April/May. Still, only 2 pc's out of 6 on the same modem/router have this problem.

Seti doesn't assume anything. When you enable the <http_debug> flag in cc_config.xml you're debugging the HTTP communications your client is doing to the outside world and the answers it gets back. It's not even BOINC assuming anything, as BOINC itself doesn't do any communications (in the strictest word). It's the Curl module built into BOINC that does the communications.

What I have seen before is that seemingly normal check connections to a project server can go lost. All next scheduler operations are then waiting for this one scheduler contact to finish. For instance, WCG will ask of BOINC to check in weekly to get the latest updates from their servers. Even when on NNT, just as long as you're attached it'll do that. And those contacts can at times go awry, supposedly due to cosmic rays hitting the junction box of your provider, or because aunt Annie decided to download all of Desperate Housewives at the exact same moment your BOINC tries to contact the server. I don't know why it happens, but I have seen contacts to other projects go sit and wait for minutes upon a time before timing out due to that stuck scheduler contact to WCG.

The only way around that I have found is to exit BOINC, wait a minute, then restart it and hoping that the other projects get their scheduler contact in before WCG does its next weekly ping.

Yet I also found that forcing BOINC to use HTTP 1.0 can solve this as well (was a couple of versions before 6.10.58 though). It doesn't hurt to try. It won't interfere with the speed of your internet connection, it's just a different protocol that the client uses to communicate with the projects. It's not a magical thing though and if it doesn't work, then it doesn't work. ;-)

---

Having said that, I should read my own FAQs... ;-)

http://boincfaq.mundayweb.com/index.php?view=504.

---