Message boards :
Number crunching :
Panic Mode On (100) Server Problems?
Message board moderation
Previous · 1 . . . 19 · 20 · 21 · 22 · 23 · 24 · 25 . . . 32 · Next
Author | Message |
---|---|
Dirk Broer Send message Joined: 18 Jun 00 Posts: 21 Credit: 5,339,302 RAC: 18 |
01-10-2015 10:29:48 | | Project communication failed: attempting access to reference site 01-10-2015 10:29:49 | | Internet access OK - project servers may be temporarily down. 01-10-2015 10:30:16 | | Project communication failed: attempting access to reference site 01-10-2015 10:30:17 | | Internet access OK - project servers may be temporarily down. 01-10-2015 12:24:57 | | Project communication failed: attempting access to reference site 01-10-2015 12:25:19 | | BOINC can't access Internet - check network connection or proxy configuration. 01-10-2015 13:03:00 | | Project communication failed: attempting access to reference site 01-10-2015 13:03:12 | | BOINC can't access Internet - check network connection or proxy configuration. 01-10-2015 14:13:16 | | Project communication failed: attempting access to reference site 01-10-2015 14:13:17 | | Internet access OK - project servers may be temporarily down. 01-10-2015 16:56:25 | | Project communication failed: attempting access to reference site 01-10-2015 16:56:47 | | BOINC can't access Internet - check network connection or proxy configuration. 01-10-2015 17:06:35 | SETI@home | update requested by user 01-10-2015 17:06:37 | SETI@home | Sending scheduler request: Requested by user. 01-10-2015 17:06:37 | SETI@home | Not requesting tasks: don't need (CPU: not highest priority project; Miner ASIC: not highest priority project; AMD/ATI GPU: job cache full) 01-10-2015 17:06:58 | SETI@home | Scheduler request failed: Couldn't connect to server 01-10-2015 17:06:59 | | Project communication failed: attempting access to reference site 01-10-2015 17:07:00 | | Internet access OK - project servers may be temporarily down. 01-10-2015 17:07:32 | | Project communication failed: attempting access to reference site 01-10-2015 17:07:33 | | Internet access OK - project servers may be temporarily down. 01-10-2015 17:09:20 | | Project communication failed: attempting access to reference site 01-10-2015 17:09:21 | | Internet access OK - project servers may be temporarily down. 01-10-2015 17:11:33 | | Project communication failed: attempting access to reference site 01-10-2015 17:11:34 | | Internet access OK - project servers may be temporarily down. 01-10-2015 17:15:04 | | Project communication failed: attempting access to reference site 01-10-2015 17:15:05 | | Internet access OK - project servers may be temporarily down. 01-10-2015 17:21:01 | | Project communication failed: attempting access to reference site 01-10-2015 17:21:02 | | Internet access OK - project servers may be temporarily down. 01-10-2015 17:32:29 | | Project communication failed: attempting access to reference site 01-10-2015 17:32:30 | | Internet access OK - project servers may be temporarily down. 01-10-2015 18:03:23 | | Project communication failed: attempting access to reference site 01-10-2015 18:03:24 | | Internet access OK - project servers may be temporarily down. 01-10-2015 18:28:37 | | Project communication failed: attempting access to reference site 01-10-2015 18:28:38 | | Internet access OK - project servers may be temporarily down. 01-10-2015 18:43:35 | | Project communication failed: attempting access to reference site 01-10-2015 18:43:36 | | Internet access OK - project servers may be temporarily down. 01-10-2015 20:45:55 | | Project communication failed: attempting access to reference site 01-10-2015 20:45:57 | | Internet access OK - project servers may be temporarily down. 01-10-2015 21:45:17 | SETI@home | update requested by user 01-10-2015 21:45:22 | SETI@home | Sending scheduler request: Requested by user. 01-10-2015 21:45:22 | SETI@home | Not requesting tasks: don't need (CPU: not highest priority project; Miner ASIC: not highest priority project; AMD/ATI GPU: job cache full) 01-10-2015 21:45:44 | SETI@home | Scheduler request failed: Couldn't connect to server 01-10-2015 21:45:46 | | Project communication failed: attempting access to reference site 01-10-2015 21:45:48 | | Internet access OK - project servers may be temporarily down. 01-10-2015 21:46:14 | | Project communication failed: attempting access to reference site 01-10-2015 21:46:15 | | Internet access OK - project servers may be temporarily down. 01-10-2015 23:22:16 | | Project communication failed: attempting access to reference site 01-10-2015 23:22:18 | | Internet access OK - project servers may be temporarily down. 01-10-2015 23:22:43 | SETI@home | update requested by user 01-10-2015 23:22:47 | SETI@home | Sending scheduler request: Requested by user. 01-10-2015 23:22:47 | SETI@home | Not requesting tasks: don't need (CPU: job cache full; Miner ASIC: not highest priority project; AMD/ATI GPU: job cache full) 01-10-2015 23:23:09 | SETI@home | Scheduler request failed: Couldn't connect to server 01-10-2015 23:23:10 | | Project communication failed: attempting access to reference site 01-10-2015 23:23:11 | | Internet access OK - project servers may be temporarily down. 01-10-2015 23:23:37 | | Project communication failed: attempting access to reference site 01-10-2015 23:23:38 | | Internet access OK - project servers may be temporarily down. |
Brent Norman Send message Joined: 1 Dec 99 Posts: 2786 Credit: 685,657,289 RAC: 835 |
Wow I got a trace route to complete
|
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
Strange you can get to muarae1 through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) but not the others; I think you can get through to all of them, but only muarae1 is configured to reveal its name in response to a tracert probe. |
geoff Send message Joined: 25 Apr 00 Posts: 123 Credit: 34,100,351 RAC: 18 |
setiboinc.ssl.berkeley.edu is accessible, it is the Apache test page, so failing to report wus is after this server. I have been unable to report wus since about 1400 yesterday. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Strange you can get to muarae1 through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) but not the others; The only one I can reach is synergy and it doesn't go through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99). Both 'download server 1 - georgem' and 'upload server - bruno' go through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) and can not be reached. See my previous posts. Apparently you can also reach vader; traceroute to vader.ssl.berkeley.edu (208.68.240.127), 64 hops max, 72 byte packets 1 192.168.1.1 (192.168.1.1) 1.032 ms 0.721 ms 0.399 ms 2 l100.tampfl-vfttp-76.verizon-gni.net (96.254.233.1) 8.188 ms 7.984 ms 7.737 ms 3 g0-5-5-0.tampfl-lcr-21.verizon-gni.net (130.81.109.254) 12.182 ms 9.745 ms 9.727 ms 4 * * * 5 0.ae3.br1.mia19.alter.net (140.222.225.111) 20.152 ms 19.550 ms 19.952 ms 6 * lag-10.ear2.miami2.level3.net (4.68.71.169) 20.136 ms 19.814 ms 7 ae-31-51.ebr1.miami1.level3.net (4.69.138.91) 69.896 ms 72.222 ms 70.430 ms 8 ae-2-2.ebr1.dallas1.level3.net (4.69.140.133) 69.643 ms 69.846 ms 69.622 ms 9 ae-71-71.csw2.dallas1.level3.net (4.69.151.137) 72.434 ms 69.303 ms 72.357 ms 10 ae-73-73.ebr3.dallas1.level3.net (4.69.151.146) 70.467 ms 71.893 ms 72.896 ms 11 ae-3-3.ebr2.losangeles1.level3.net (4.69.132.77) 69.459 ms 69.561 ms 69.688 ms 12 ae-92-92.csw4.losangeles1.level3.net (4.69.137.30) 72.406 ms 72.138 ms 69.649 ms 13 * * * 14 cenic.ear1.losangeles1.level3.net (4.35.156.66) 71.076 ms 69.449 ms 69.726 ms 15 dc-svl-agg4--lax-agg6-100ge.cenic.net (137.164.11.1) 80.117 ms 78.655 ms 79.892 ms 16 dc-oak-agg4--svl-agg4-100ge.cenic.net (137.164.46.144) 80.287 ms 79.240 ms 79.861 ms 17 ucb--oak-agg4-10g.cenic.net (137.164.50.31) 84.935 ms 79.250 ms 80.214 ms 18 t2-3.inr-201-sut.berkeley.edu (128.32.0.37) 81.834 ms 79.879 ms 79.857 ms 19 et3-48.inr-311-ewdc.berkeley.edu (128.32.0.101) 82.140 ms 81.562 ms 83.228 ms 20 et3-48.inr-311-ewdc.berkeley.edu (128.32.0.101) 1454.793 ms !H 2996.669 ms !H 3035.443 ms !H It doesn't use e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) either. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
setiboinc.ssl.berkeley.edu is accessible, it is the Apache test page, so failing to report wus is after this server. I have been unable to report wus since about 1400 yesterday. Did you see my edit to message 1730835? The full scheduler url is http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi and responds correctly. The Apache test page simply shows that this server hasn't been configured as a web server: it has a different role to perform. |
Bruce Send message Joined: 15 Mar 02 Posts: 123 Credit: 124,955,234 RAC: 11 |
Richard I tried to trace setiboinc.ssl.berkeley.edu and got this: Tracing route to setiboinc.ssl.berkeley.edu [208.68.240.126] over a maximum of 30 hops: 11 75 ms 77 ms 75 ms calren-cenic.paix.net [198.32.176.33] 12 77 ms 78 ms 77 ms dc-oak-agg4--paix-px1-ge.cenic.net [137.164.47.19] 13 78 ms 78 ms 78 ms ucb--oak-agg4-10g.cenic.net [137.164.50.31] 14 275 ms 78 ms 79 ms t2-3.inr-201-sut.Berkeley.EDU [128.32.0.37] 15 78 ms 78 ms 78 ms et3-48.inr-311-ewdc.Berkeley.EDU [128.32.0.101] 16 et3-48.inr-311-ewdc.Berkeley.EDU [128.32.0.101] reports: Destination host unreachable. Trace complete. I also tried to put the complete URL into the browser bar, and it just timed out. Any more suggestions? Thanks Bruce Bruce |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
Strange you can get to muarae1 through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) but not the others; And my previous posts? So far as I can diagnose, the main problem is reaching setiboinc.ssl.berkeley.edu (that's synergy, the scheduling server) through et3-47.inr-311 or et3-48.inr-311 - that combination consistently comes back (from the routing chosen by my ISP) as "Destination host unreachable". That at least is explicit, unlike the rows of asterisks which you are interpreting as 'can't get through', and I'm interpreting as 'stealthed - no name revealed' (but active). |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Strange you can get to muarae1 through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) but not the others; Vader is a DL server, just as georgem. Apparently you can also reach vader; traceroute to vader.ssl.berkeley.edu (208.68.240.127), 64 hops max, 72 byte packets 1 192.168.1.1 (192.168.1.1) 1.032 ms 0.721 ms 0.399 ms 2 l100.tampfl-vfttp-76.verizon-gni.net (96.254.233.1) 8.188 ms 7.984 ms 7.737 ms 3 g0-5-5-0.tampfl-lcr-21.verizon-gni.net (130.81.109.254) 12.182 ms 9.745 ms 9.727 ms 4 * * * 5 0.ae3.br1.mia19.alter.net (140.222.225.111) 20.152 ms 19.550 ms 19.952 ms 6 * lag-10.ear2.miami2.level3.net (4.68.71.169) 20.136 ms 19.814 ms 7 ae-31-51.ebr1.miami1.level3.net (4.69.138.91) 69.896 ms 72.222 ms 70.430 ms 8 ae-2-2.ebr1.dallas1.level3.net (4.69.140.133) 69.643 ms 69.846 ms 69.622 ms 9 ae-71-71.csw2.dallas1.level3.net (4.69.151.137) 72.434 ms 69.303 ms 72.357 ms 10 ae-73-73.ebr3.dallas1.level3.net (4.69.151.146) 70.467 ms 71.893 ms 72.896 ms 11 ae-3-3.ebr2.losangeles1.level3.net (4.69.132.77) 69.459 ms 69.561 ms 69.688 ms 12 ae-92-92.csw4.losangeles1.level3.net (4.69.137.30) 72.406 ms 72.138 ms 69.649 ms 13 * * * 14 cenic.ear1.losangeles1.level3.net (4.35.156.66) 71.076 ms 69.449 ms 69.726 ms 15 dc-svl-agg4--lax-agg6-100ge.cenic.net (137.164.11.1) 80.117 ms 78.655 ms 79.892 ms 16 dc-oak-agg4--svl-agg4-100ge.cenic.net (137.164.46.144) 80.287 ms 79.240 ms 79.861 ms 17 ucb--oak-agg4-10g.cenic.net (137.164.50.31) 84.935 ms 79.250 ms 80.214 ms 18 t2-3.inr-201-sut.berkeley.edu (128.32.0.37) 81.834 ms 79.879 ms 79.857 ms 19 et3-48.inr-311-ewdc.berkeley.edu (128.32.0.101) 82.140 ms 81.562 ms 83.228 ms 20 et3-48.inr-311-ewdc.berkeley.edu (128.32.0.101) 1454.793 ms !H 2996.669 ms !H 3035.443 ms !H It doesn't use e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) either. No problem with synergy.ssl.berkeley.edu or setiboinc.ssl.berkeley.edu; traceroute to synergy.ssl.berkeley.edu (208.68.240.126), 64 hops max, 72 byte packets 1 192.168.1.1 (192.168.1.1) 0.895 ms 0.560 ms 0.442 ms 2 l100.tampfl-vfttp-76.verizon-gni.net (96.254.233.1) 8.562 ms 8.374 ms 5.681 ms 3 g0-5-5-0.tampfl-lcr-22.verizon-gni.net (130.81.110.228) 10.467 ms 12.573 ms 10.213 ms 4 * * * 5 0.ae4.br1.mia19.alter.net (140.222.225.113) 16.848 ms 16.619 ms 18.498 ms 6 * * * 7 ae-31-51.ebr1.miami1.level3.net (4.69.138.91) 70.927 ms 68.923 ms 70.445 ms 8 ae-2-2.ebr1.dallas1.level3.net (4.69.140.133) 67.910 ms 68.876 ms 70.407 ms 9 ae-71-71.csw2.dallas1.level3.net (4.69.151.137) 66.598 ms 69.800 ms 67.436 ms 10 ae-73-73.ebr3.dallas1.level3.net (4.69.151.146) 69.637 ms 69.828 ms 69.641 ms 11 ae-3-3.ebr2.losangeles1.level3.net (4.69.132.77) 70.175 ms 69.365 ms 70.331 ms 12 ae-82-82.csw3.losangeles1.level3.net (4.69.137.26) 69.734 ms 69.815 ms 69.736 ms 13 * * ae-3-80.ear1.losangeles1.level3.net (4.69.144.146) 69.610 ms 14 cenic.ear1.losangeles1.level3.net (4.35.156.66) 72.047 ms 69.532 ms 70.405 ms 15 dc-svl-agg4--lax-agg6-100ge.cenic.net (137.164.11.1) 77.198 ms 76.836 ms 77.674 ms 16 dc-oak-agg4--svl-agg4-100ge.cenic.net (137.164.46.144) 79.919 ms 79.469 ms 79.893 ms 17 ucb--oak-agg4-10g.cenic.net (137.164.50.31) 80.174 ms 79.456 ms 79.903 ms 18 t2-3.inr-202-reccev.berkeley.edu (128.32.0.39) 79.889 ms 79.415 ms 80.158 ms 19 et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103) 79.853 ms 79.539 ms 79.896 ms 20 * et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103) 834.904 ms !H * 21 et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103) 1076.594 ms !H * 1045.139 ms !H traceroute to setiboinc.ssl.berkeley.edu (208.68.240.126), 64 hops max, 72 byte packets 1 192.168.1.1 (192.168.1.1) 1.566 ms 0.899 ms 2.027 ms 2 l100.tampfl-vfttp-76.verizon-gni.net (96.254.233.1) 8.510 ms 6.175 ms 7.507 ms 3 g0-5-5-0.tampfl-lcr-22.verizon-gni.net (130.81.110.228) 10.440 ms 11.989 ms 12.743 ms 4 * * * 5 0.ae4.br1.mia19.alter.net (140.222.225.113) 17.883 ms 41.065 ms 24.951 ms 6 lag-10.ear2.miami2.level3.net (4.68.71.169) 17.979 ms 16.576 ms 18.695 ms 7 ae-31-51.ebr1.miami1.level3.net (4.69.138.91) 69.439 ms 69.946 ms 69.459 ms 8 ae-2-2.ebr1.dallas1.level3.net (4.69.140.133) 70.410 ms 71.108 ms 69.756 ms 9 ae-71-71.csw2.dallas1.level3.net (4.69.151.137) 68.024 ms 69.923 ms 69.677 ms 10 ae-73-73.ebr3.dallas1.level3.net (4.69.151.146) 70.468 ms 70.837 ms 69.926 ms 11 ae-3-3.ebr2.losangeles1.level3.net (4.69.132.77) 67.937 ms 69.898 ms 66.477 ms 12 ae-82-82.csw3.losangeles1.level3.net (4.69.137.26) 70.157 ms 72.756 ms 69.423 ms 13 * * * 14 cenic.ear1.losangeles1.level3.net (4.35.156.66) 71.112 ms 70.298 ms 69.129 ms 15 dc-svl-agg4--lax-agg6-100ge.cenic.net (137.164.11.1) 77.938 ms 76.510 ms 77.736 ms 16 dc-oak-agg4--svl-agg4-100ge.cenic.net (137.164.46.144) 79.896 ms 79.643 ms 79.781 ms 17 ucb--oak-agg4-10g.cenic.net (137.164.50.31) 79.917 ms 79.488 ms 79.916 ms 18 t2-3.inr-202-reccev.berkeley.edu (128.32.0.39) 80.193 ms 79.144 ms 79.938 ms 19 et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103) 79.926 ms 79.383 ms 80.184 ms 20 et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103) 1479.304 ms !H * 1102.453 ms !H |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
I also tried to put the complete URL into the browser bar, and it just timed out. That confirms the same blockage that I've just tried to describe to TBar. I'm getting through roughly 50% of my attempts - it seems to vary from ISP to ISP. I must have hit lucky when I tried that full cgi address, and pasted the reply. The only suggestion from that point forward is abuse of the update button. Or drowning your sorrows in a pint of beer, which it where I'm heading now. Time out. |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
Well, here's the difference when I can reach the BOINC forums, as I now can. It's as if someone got off the line. 14:51 in San Francisco, someone went home early to prepare a secret for my birthday in 8 minutes? Tracing route to boinc.berkeley.edu [208.68.240.115] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 6 ms 10 ms 6 ms 10.254.138.1 3 7 ms 7 ms 7 ms tb-rc0001-cr101-xe-0-3-4-0.core.as9143.net [213.51.186.180] 4 10 ms 10 ms 9 ms asd-tr0042-cr101-ae5-0.core.as9143.net [213.51.158.18] 5 12 ms 10 ms 9 ms lag-19.ear2.Amsterdam1.Level3.net [212.72.42.245] 6 * * 154 ms ae-2-70.ear1.SanJose1.Level3.net [4.69.152.87] 7 156 ms 155 ms 154 ms ae-2-70.ear1.SanJose1.Level3.net [4.69.152.87] 8 168 ms 169 ms 169 ms CENIC.ear1.SanJose1.Level3.net [4.15.122.46] 9 170 ms 171 ms 169 ms dc-oak-agg4--svl-agg4-100ge.cenic.net [137.164.46.144] 10 171 ms 172 ms 171 ms ucb--oak-agg4-10g.cenic.net [137.164.50.31] 11 170 ms 171 ms 171 ms t2-3.inr-201-sut.Berkeley.EDU [128.32.0.37] 12 170 ms 171 ms 171 ms et3-48.inr-311-ewdc.Berkeley.EDU [128.32.0.101] 13 170 ms 172 ms 171 ms isaac.ssl.berkeley.edu [208.68.240.115] Trace complete. |
Bruce Send message Joined: 15 Mar 02 Posts: 123 Credit: 124,955,234 RAC: 11 |
I also tried to put the complete URL into the browser bar, and it just timed out. LOL. Since I'm a tea totaller, I will have to settle for Earl Grey for my drowning. Bruce Bruce |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
And BOINC forums are again out of my reach. Oh well. |
Cosmic_Ocean Send message Joined: 23 Dec 00 Posts: 3027 Credit: 13,516,867 RAC: 13 |
Strange you can get to muarae1 through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) but not the others; This is true. Or even on the router's viewpoints, this is completely logical to explain. A few years ago, I was going through the CCNA/CCNP program (got my CCNA cert, took two of the four classes for P, and that's as far as I went) and on the routers, you can set up Access Control Lists (ACLs). One of the main things we did in the configuration assignments were to block certain types of traffic from certain areas of multiple networks. For example, on one router, have it completely drop all incoming ping traffic, but allow outgoing pings. But that didn't mean that all outside traffic was blocked from accessing anything behind that router, just ping traffic was blocked. Could be something similar. As far as the inr-310/311 thing that Richard also mentioned 100+ posts back.. after that upgrade a couple months ago, that was one of the first things I noted when we were waiting for the Cricket graphs to come back. We used to be on inr-210/211, and it looks like the upgraded routers just moved up into the 300s, basically. I'm pretty sure I mentioned all of this way back then. As far as the route changing from 310 to 311 and different ports on each every time you try to trace the route, that is most likely load-balancing efforts, and it would not surprise me at all if there are redundant paths to at least the switch in the rack for all the servers, and it also would not surprise me if there were two switches in the rack and every server has two NICs. We used redundant paths in one of the CCNP classes and those were fun to set up, but they were also a logical headache at the same time. They aren't difficult to configure, but they are incredibly easy to botch the entire config and it is often difficult to pin-point exactly where it got botched. You can either set up redundant paths to be strictly a fail-over/backup, or you can configure load-balancing, or even link aggregation (taking two 1gbit physical links and turning them into one 2gbit virtual interface on both ends). Networking is really fun to design, then configure (when you know how to do it and aren't referring to tutorials you found on Google), and then see them in action. Diagnosing what went wrong is not fun at all, especially when you can't just wipe the configuration and start over, because then everything would be unreachable for everyone in the time that you're attempting to re-configure everything from scratch. Doing it live is difficult, and often.. does not yield the expected result because some part of what was done actually needs the device to be power cycled. What could be done in this case, since it appears there are redundant paths, is to unplug one of them, start over from scratch on that one, then bring it back online, make sure it works, then do the same with the other one.. but then there's no guarantee that once the two are back up and running, they'll mesh together as expected.. which I'm thinking is probably what's going on here. Just my humble opinion on this topic. Load balancing is probably the main part of the problem, and either it needs to be configured to be primary and fail-over, or configure it to be aggregated. Load balancing and changing the route frequently can be very confusing..especially for dynamic routing tables. [edit: I seem to recall, actually, that before the upgrade, we were primarily on 210 or 211 99% of the time. Something would go wrong, and we'd end up on the other one instead, until the problem was fixed, and then it would switch back over. So in the old setup, it was configured to be primary and fail-over.] Linux laptop: record uptime: 1511d 20h 19m (ended due to the power brick giving-up) |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Every Traceroute I've run has setiboinc.ssl.berkeley.edu at et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103). Not a single one has listed e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99). My hosts are at least Reporting and Receiving New tasks. traceroute to setiboinc.ssl.berkeley.edu (208.68.240.126), 64 hops max, 72 byte packets |
Bart Send message Joined: 23 Apr 03 Posts: 17 Credit: 3,080,489 RAC: 27 |
The only suggestion from that point forward is abuse of the update button. This worked! |
Oz Send message Joined: 6 Jun 99 Posts: 233 Credit: 200,655,462 RAC: 212 |
yeah same traceroute as everyone else Sorry Zombu2, I should have made it simpler: Here is a tracert from one of my boxes that has NOT been connecting... >ipconfig /flushdns Windows IP Configuration Successfully flushed the DNS Resolver Cache. >tracert setiathome.berkeley.edu Tracing route to setiathome.berkeley.edu [208.68.240.110] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms xxx 2 * * * Request timed out. 3 22 ms 31 ms 31 ms xxx 4 12 ms 12 ms 10 ms xxx 5 14 ms 13 ms 15 ms xxx 6 28 ms 29 ms 29 ms bu-ether15.chcgildt87w-bcr00.tbone.rr.com [66.10 9.6.72] 7 33 ms 26 ms 28 ms 0.ae1.pr1.chi10.tbone.rr.com [107.14.17.194] 8 36 ms 27 ms 28 ms xe-4-2-0.0.chic0.tr-cps.internet2.edu [64.57.20. 53] 9 26 ms 26 ms 27 ms ae-5.80.rtr.chic.net.internet2.edu [64.57.20.150 ] 10 39 ms 37 ms 36 ms ae-0.80.rtr.kans.net.internet2.edu [64.57.20.148 ] 11 76 ms 93 ms 78 ms ae-0.80.rtr.salt.net.internet2.edu [64.57.20.146 ] 12 72 ms 78 ms 73 ms ae-2.80.rtr.losa.net.internet2.edu [64.57.20.144 ] 13 79 ms 78 ms 77 ms xe-0-0-0.80.rtr.paix.net.internet2.edu [64.57.20 .125] 14 78 ms 78 ms 78 ms 64.57.21.7 15 79 ms 81 ms 81 ms dc-oak-agg4--svl-agg4-100ge.cenic.net [137.164.4 6.144] 16 80 ms 82 ms 82 ms ucb--oak-agg4-10g.cenic.net [137.164.50.31] 17 81 ms 83 ms 81 ms t2-3.inr-202-reccev.Berkeley.EDU [128.32.0.39] 18 82 ms 82 ms 87 ms e3-47.inr-310-ewdc.Berkeley.EDU [128.32.0.99] 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. And here is a tracert from one of my boxes that has been connecting... Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. >tracert -h 20 -w 15001 setiathome.berkeley.edu Tracing route to setiathome.berkeley.edu [208.68.240.110] over a maximum of 20 hops: 1 <1 ms <1 ms <1 ms xxx 2 3 ms 4 ms 4 ms xxx 3 7 ms 7 ms 7 ms xxx 4 * * * Request timed out. 5 * * * Request timed out. 6 16 ms 16 ms 15 ms 0.ae2.BR3.NYC4.ALTER.NET [140.222.229.99] 7 * * * Request timed out. 8 75 ms 74 ms 74 ms ae-3-80.ear1.SanJose1.Level3.net [4.69.152.150] 9 * * * Request timed out. 10 73 ms 73 ms 73 ms CENIC.ear1.SanJose1.Level3.net [4.15.122.46] 11 74 ms 75 ms 74 ms dc-oak-agg4--svl-agg4-100ge.cenic.net [137.164.46.144] 12 75 ms 81 ms 76 ms ucb--oak-agg4-10g.cenic.net [137.164.50.31] 13 75 ms 74 ms 74 ms t2-3.inr-201-sut.Berkeley.EDU [128.32.0.37] 14 75 ms 75 ms 74 ms et3-48.inr-311-ewdc.Berkeley.EDU [128.32.0.101] 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. Trace complete. Note that they have not one single node in common. Member of the 20 Year Club |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
According to David the routing problem is fixed. Or maybe that's just the routing to the BOINC Domain, as I still can't report my (now) 38 results. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
yeah same traceroute as everyone else You're tracing to the website in both cases, which has no bearing on whether you can "connect" a cruncher to a server. You would need to trace to one of the other data servers (upload, download, scheduling - wherever the problem is) to get any insight into that. |
Oz Send message Joined: 6 Jun 99 Posts: 233 Credit: 200,655,462 RAC: 212 |
yeah same traceroute as everyone else Yes, I noticed that in the preceding discussions and was about to try it, but just wanted to clarify that what I had previously posted was not "the same" Member of the 20 Year Club |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.