And the kitties can't find their fish.

just open the door, wabbit is good! yumm;P

---

My pings from Australia get NO response! :(

I have a machine which has spent almost a week trying to connect. Again :(

So... If you have connected in recent days, "kwitchawinjin!" [Quit your winging!]

---

That should read "whinging" (aka whining, pining, meowing, etc)

---

I have about 2000 run unit to upload and zero work in one host.
Also in the zero job host I see that is "not requesting new tasks" (!!)

using pathping I see the same situation of others (100% lost in some hop) so I don't add my data.
Instead I think that this trace (from switzerland to Berleley) can be interesting



Bye,
Franz

---

My effort from Central Australia

Tracing route to boinc2.ssl.berkeley.edu [208.68.240.18]
over a maximum of 30 hops:

<snip>

All ping times within tolerance and zero packet loss till it gets to here

12 271ms 1/ 100 = 1% 1/ 100 = 1% 10gigabitethernet2-1.core1.lax1.he.net [72.52.92.121] 0/ 100 = 0%

13 285ms 0/ 100 = 0% 0/ 100 = 0% 10gigabitethernet1-3.core1.pao1.he.net [72.52.92.21] 0/ 100 = 0%

14 285ms 0/ 100 = 0% 0/ 100 = 0% 64.71.140.42 8/ 100 = 8%

15 278ms 8/ 100 = 8% 0/ 100 = 0% 208.68.243.254 1/ 100 = 1%

16 281ms 9/ 100 = 9% 0/ 100 = 0% boinc2.ssl.berkeley.edu [208.68.240.18]

Trace complete.

The coresite.com switch must be set to silent, it doesn't respond to a straight ping test either.

Maybe the traffic for SAH is clogging the upstream switching as well ?

Brodo

Just one idea.
Recently I have read about a big hacker attack and may be a lot defense policies have been implemented in some hops.
Maybe some of them are disturbing seti traffic.

Hy
Franz

---

Looks like something is moving out there in the ether. The 56 wu's I have been trying to report all week have all reported OK, but can't get any new work.

Hurrah - new work

---

Looks like something is moving out there in the ether. The 56 wu's I have been trying to report all week have all reported OK, but can't get any new work.

Hurrah - new work

Not here:

20.02.2010 12:26:28 Project communication failed: attempting access to reference site
20.02.2010 12:26:28 SETI@home Temporarily failed upload of 13dc06ac.11083.9888.6.10.185_0_0: HTTP error
20.02.2010 12:26:28 SETI@home Backing off 3 hr 4 min 7 sec on upload of 13dc06ac.11083.9888.6.10.185_0_0
20.02.2010 12:26:31 Internet access OK - project servers may be temporarily down.
20.02.2010 12:27:02 SETI@home update requested by user
20.02.2010 12:27:06 SETI@home Sending scheduler request: Requested by user.
20.02.2010 12:27:06 SETI@home Reporting 9 completed tasks, not requesting new tasks
20.02.2010 12:27:28 Project communication failed: attempting access to reference site
20.02.2010 12:27:29 Internet access OK - project servers may be temporarily down.
20.02.2010 12:27:31 SETI@home Scheduler request failed: Couldn't connect to server

The Cricket graph is showing something like himalaya skyline:
http://fragment1.berkeley.edu/newcricket/grapher.cgi?target=%2Frouter-interfaces%2Finr-250%2Fgigabitethernet2_3;view=Octets;ranges=d%3Aw%3Am%3Ay
Bye
Franz

---

I was able to Update this morning here, but still have ~50 uploads pending in the queue. Some uploads must be trickling through from time to time. Curiously, no new work was requested! I don't really understand that.

I'm still seeing some losses on the west coast (only).

10 88ms 0/ 100 = 0% 0/ 100 = 0% 64.71.140.42
6/ 100 = 6% |
11 96ms 6/ 100 = 6% 0/ 100 = 0% 208.68.243.254
7/ 100 = 7% |
12 88ms 13/ 100 = 13% 0/ 100 = 0% boinc2.ssl.berkeley.edu [208.68.240.18]

Trace complete.

Martin
Nevermind, the light came on - uploads pending = no downloads. ok...

This is the longest time that uploads/updates have continuously failed/backed-off for this project I have ever seen. The problem did start before the A/C outage. (Just an observation.)

Many thanks, and good luck, to those in charge, dealing with the frustrations of modern computers.

Boinc won't ask for work from a project, if the the number of uploads for that project exceeds twice the number of CPU cores,
so until you're down to a handfull of uploads, you'll get no downloads from Seti,
But you can still get work from other projects.

Claggy

---

Boinc won't ask for work from a project, if the the number of uploads for that project exceeds twice the number of CPU cores,
so until you're down to a handfull of uploads, you'll get no downloads from Seti,
But you can still get work from other projects.

Claggy

If you’re looking for an interesting task to sick your GPU’s on, check out Collatz Conjecture at http://boinc.thesonntags.com/collatz/ They’re called Wondrous Numbers (really).

For the CPU, there are projects to help improve the human condition at World Community Grid. http://www.worldcommunitygrid.org/

It seems like a provider peering issue. Here's my trace route from Palisades Park, NJ on TimeWarner Roadrunner. The trace takes a dump midway on the rr.com network and it gets worse on the Hurrican Electric he.net network.

C:\>tracert 208.68.240.16

Tracing route to setiboincdata.ssl.berkeley.edu [208.68.240.16]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.101.1
2 6 ms 7 ms 7 ms 10.50.96.1
3 6 ms 7 ms 7 ms ge3-2-njmnyhubp-rtr1.nj.rr.com [24.168.128.146]
4 8 ms 9 ms 8 ms cpe-24-29-150-94.nyc.res.rr.com [24.29.150.94]
5 9 ms 10 ms 9 ms tenge-0-1-0-nwrknjmd-rtr.nyc.rr.com [24.29.119.150]
6 38 ms 9 ms 11 ms ae-4-0.cr0.nyc30.tbone.rr.com [66.109.6.78]
7 10 ms 10 ms 10 ms ae-0-0.cr0.nyc20.tbone.rr.com [66.109.6.27]
8 89 ms 89 ms 91 ms 66.109.6.10
9 159 ms 91 ms 91 ms ae-1-0.pr0.sjc10.tbone.rr.com [66.109.6.137]
10 110 ms 100 ms 101 ms gige-g5-6.core1.sjc2.he.net [216.218.135.225]
11 100 ms 101 ms 100 ms 10gigabitethernet3-2.core1.pao1.he.net [72.52.92.69]
12 100 ms 100 ms 100 ms 64.71.140.42
13 * 113 ms 105 ms 208.68.243.254
14 106 ms 105 ms 105 ms setiboincdata.ssl.berkeley.edu [208.68.240.16]

Trace complete.

Also is ping allowed on 208.68.243.254? Is that your router?

Doing an extended ping to 208.68.243.254 for about a minute I get multiple Request Timed Out, packet loss is among us:

C:\>ping 208.68.243.254 -t

Pinging 208.68.243.254 with 32 bytes of data:
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=241
Reply from 208.68.243.254: bytes=32 time=105ms TTL=241
Reply from 208.68.243.254: bytes=32 time=110ms TTL=242
Reply from 208.68.243.254: bytes=32 time=104ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=241
Reply from 208.68.243.254: bytes=32 time=106ms TTL=241
Reply from 208.68.243.254: bytes=32 time=106ms TTL=241
Reply from 208.68.243.254: bytes=32 time=108ms TTL=241
Reply from 208.68.243.254: bytes=32 time=106ms TTL=241
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=241
Request timed out.
Reply from 208.68.243.254: bytes=32 time=104ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=241
Reply from 208.68.243.254: bytes=32 time=104ms TTL=242
Reply from 208.68.243.254: bytes=32 time=107ms TTL=241
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=107ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=104ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=241
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=104ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=110ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=107ms TTL=241
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=241
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Request timed out.
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=241
Reply from 208.68.243.254: bytes=32 time=104ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=241
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=241
Request timed out.
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=241
Reply from 208.68.243.254: bytes=32 time=104ms TTL=242
Reply from 208.68.243.254: bytes=32 time=107ms TTL=242
Reply from 208.68.243.254: bytes=32 time=108ms TTL=242
Reply from 208.68.243.254: bytes=32 time=106ms TTL=241
Request timed out.
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=105ms TTL=241
Reply from 208.68.243.254: bytes=32 time=105ms TTL=242
Reply from 208.68.243.254: bytes=32 time=107ms TTL=242

Ping statistics for 208.68.243.254:
Packets: Sent = 71, Received = 67, Lost = 4 (5% loss),
Approximate round trip times in milli-seconds:
Minimum = 104ms, Maximum = 110ms, Average = 105ms
Control-C
^C
C:\>

Sorry for the multiple posts, didn't see the Edit button, I'm a noob on this forum :P

SJ, it's working from here (Maryland)-7% loss.

Martin

edited//

ping -t to the previous location, 64.71.140.42, are perfect. No loss at all.

SJ, it's working from here (Maryland)-7% loss.

Martin

edited//

ping -t to the previous location, 64.71.140.42, are perfect. No loss at all.

100% packet loss from me in Sweden.

Looking at the cricket graphs, the bandwidth utilization is much lower than normal. I would say that it's a router or switch issue, either on SETI location, or somewhere in between the users and berkeley.

Sten-Arne

Did you see my observations with Wireshark and a fortuitous download in Panic mode...? I have no prior experience with Wireshark (willing to learn if anyone here can guide me), and it's fearsomely powerful (i.e. complicated), but what I saw led me to the opposite conclusion.

Things just doesn't get through, and it's not because of maxed out bandwidth...

Fully agree with that. But the packets I was wiresharking (from the UK) seemed to have a reasonable chance of reaching Berkeley, getting through all the routers and switches, and starting to communicate with Bruno. It's the RST+ACK from Bruno that seems to be causing the problem (for uploads: I haven't tried probing Anakin - scheduler - yet).

I'm in no hurry. If my PC's runs out of WU's to crunch, I'll just shut them down and go out and play in the snow :-)

I agree. I still have a couple days worth of VLARs for the CPU to chew on.

BTW: Are you losing 100% just in Calif or before?

@Richard Yes, we could use some expertise I think.

Martin