I'm not sure you understand -- All of my WUs are finally uploaded -- But I C A N - N O T CONNECT TO R E P O R T Them For More Than 48 Hours!!! I don't think this has anything to do with splitters being down.

It's aggravating that some people simply aren't seeing this problem while others have been seeing this even before the AC crash and the first group is saying "all is well".

Fwiw, I've got more than a couple of computers trying to send results over the last 72 to 96 hours. They managed to get about 75% through since the recovery from the A/C failure (but I was certainly having problems before then) - the rest are sitting here trying to upload but getting HTTP errors and backing off, and when they can connect to download they're being told the project has no jobs available (that may be true given the onslaught of people trying to catch up, i don't know).

I'm in the 'something's still not quite right' camp, but just holding out, since there's obviously not much we can do.

If nothing else it's a good reminder to take a breath. Maybe some of us get tunnelvision for numbercrunching.... must get more!mustgetmore! or maybe that's just me. dunno yet.

Either way, hat's off to the S@H team for giving it all they've got, and hope all have a great weekend.

[/quote]

... One of the raid arrays on thumper lost a drive...

you guys seem to loose way to many drives! how many do you have?



anybody got work?

---

Superjoker: as explained elsewhere the backoffs are our friend as without them the servers would be flooded with requests & no-one would get anywhere. The longer the backoffs the better as it spreads the load more.

Backoffs are a perfect technique for spreading the load when when the complete system is capable of handling (with an adequate satety margin) the aggregate anticipated demand averaged over an extended period of time. That's how SETI normally runs, and a few backoffs to shave the peaks and fill the troughs are exactly what's needed.

Backoffs do not help if the aggregate load exceeds - over an extended period - the system's capacity to absorb work. Then you have to take more drastic action, to reduce demand or increase supply.

For the last 4.5 days (only), SETI's capacity to absorb work has been below demand. I see no sign that demand has increased: instead, it seems to me that capacity has decreased (hopefully, temporarily).

No amount of smoothing (backoffs) will solve this. What is needed is to restore the status quo ante on the capacity side.

BOINC has a built in mechanism for this as well. If there are more than 2 * ncpus results waiting for uploads, no work will be requested. This was originally put in place to limit the growth on the client for a couple of projects where the upload time exceeded the crunch time. It also has the effect of limiting work being done if upload is slowed for an extended period.

---

BOINC WIKI

... One of the raid arrays on thumper lost a drive...

you guys seem to loose way to many drives! how many do you have?



anybody got work?

Lots and lots of work from many projects (just not much from SETI).

---

BOINC WIKI

I can not UL thousands of results and not report/request new work.

Since days only idle PCs.

It's not at my side, DSL router switched off/on and PCs rebooted.


Yes, sure.. I'm patiently..
Only for info.


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations, which are used often in forum and their meaning.]

---

Guess this weekend sucks for seti....

2/19/2010 5:17:07 PM SETI@home Reporting 384 completed tasks, not requesting new tasks
2/19/2010 5:17:29 PM Project communication failed: attempting access to reference site
2/19/2010 5:17:30 PM Internet access OK - project servers may be temporarily down.
2/19/2010 5:17:32 PM SETI@home Scheduler request failed: Couldn't connect to server

---

Official Abuser of Boinc Buttons...
And no good credit hound!

Guess this weekend sucks for seti....

2/19/2010 5:17:07 PM SETI@home Reporting 384 completed tasks, not requesting new tasks
2/19/2010 5:17:29 PM Project communication failed: attempting access to reference site
2/19/2010 5:17:30 PM Internet access OK - project servers may be temporarily down.
2/19/2010 5:17:32 PM SETI@home Scheduler request failed: Couldn't connect to server

Dittos here - has anybody a clue as to why this is happening? It's been several days, and not a hint as to what is going on.....

---

Until about 2am PST, Sure, I've got work, After that, I doubt It highly. It's going to be colder than usual in the morning here(I leave the heater off at night since I'm the only living person around here anymore). Mom doesn't need anything as She's happy on Her shelf in My closet for eternity. :D

we got snow in the forcast for early next week, so it looks like i will be in the cold with you. it's just me and my doberman, i pitty the person who tries and rip me off. i'm sure the staff went home, so this is it for the week end, with just noise on the inlet pipe of clients trying to upload, but no one is home.

---

Pathping is reporting some packet losses in the San Jose area.

The command in XP is

C:\pathping 208.68.240.16 boinc2.ssl.berkeley.edu

The ip address is the upload server (from my hosts file). You need both parts - the ip and the name. Pathping /? for options.

The losses aren't huge pct-wise, but they are consistent.

Martin

Had over 100 uploads at 15:30 Central time. It is now 20:14 Central time and all uploads have completed. The "ready to upload" feature is still having problems connecting. I'm just letting the system do what it does.

---

Eric:

Thanks for the update.

FYI: While the recovery from the A/C outage was happening my Mac 10.5.8 was not having problems reporting work units. My PC XP Pro was timing out. I suspect that the Mac has a better TCP/IP stack. My pointing this out is I don't know if there is anything you can tune on your side to assist in a recovery for the PC crowd. If both sides don't time out at about the same time, that will clog the pipes and make it more painful for everyone.

Hope the rain isn't too fast and furious up there. About to start here in LA LA land.

---

C:\>pathping 208.68.240.16 boinc2.ssl.berkeley.edu

Tracing route to boinc2.ssl.berkeley.edu [208.68.240.18]
over a maximum of 30 hops:
  0  SkullStation [192.168.1.113]
  1  ORION [192.168.1.1]
  2  cab1-1.1scom.net [66.182.x.x]
  3  DSL2-5.1scom.net [66.182.x.x]
  4  Texas-Independent-Energy6328-custidna.cust-rtr.swbell.net [151.164.76.189]
  5     *     bb2-p7-1.rcsntx.sbcglobal.net [151.164.190.248]
  6  ppp-151-164-52-78.rcsntx.swbell.net [151.164.52.78]
  7     *     asn6939-he.eqdltx.sbcgobal.net [151.164.248.150]
  8  10gigabitethernet1-2.core1.lax1.he.net [72.52.92.57]
  9  10gigabitethernet1-3.core1.pao1.he.net [72.52.92.21]
 10     *     64.71.140.42
 11  208.68.243.254
 12  boinc2.ssl.berkeley.edu [208.68.240.18]

Computing statistics for 300 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           SkullStation [192.168.1.113]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  ORION [192.168.1.1]
                                0/ 100 =  0%   |
  2   14ms     0/ 100 =  0%     0/ 100 =  0%  cab1-1.1scom.net [66.182.x.x]
                                0/ 100 =  0%   |
  3   15ms     0/ 100 =  0%     0/ 100 =  0%  DSL2-5.1scom.net [66.182.x.x]
                                0/ 100 =  0%   |
  4   12ms     0/ 100 =  0%     0/ 100 =  0%  Texas-Independent-Energy6328-custidna.cust-rtr.swbell.net [151.164.76.189]
                                0/ 100 =  0%   |
  5  ---     100/ 100 =100%   100/ 100 =100%  bb2-p7-1.rcsntx.sbcglobal.net [151.164.190.248]
                                0/ 100 =  0%   |
  6  ---     100/ 100 =100%   100/ 100 =100%  ppp-151-164-52-78.rcsntx.swbell.net [151.164.52.78]
                                0/ 100 =  0%   |
  7   13ms     0/ 100 =  0%     0/ 100 =  0%  asn6939-he.eqdltx.sbcgobal.net [151.164.248.150]
                                0/ 100 =  0%   |
  8   51ms     0/ 100 =  0%     0/ 100 =  0%  10gigabitethernet1-2.core1.lax1.he.net [72.52.92.57]
                                0/ 100 =  0%   |
  9   59ms     0/ 100 =  0%     0/ 100 =  0%  10gigabitethernet1-3.core1.pao1.he.net [72.52.92.21]
                                0/ 100 =  0%   |
 10   59ms     0/ 100 =  0%     0/ 100 =  0%  64.71.140.42
                                6/ 100 =  6%   |
 11   64ms     6/ 100 =  6%     0/ 100 =  0%  208.68.243.254
                                1/ 100 =  1%   |
 12   62ms     7/ 100 =  7%     0/ 100 =  0%  boinc2.ssl.berkeley.edu [208.68.240.18]

Trace complete.

line 5 and 6 don't look good, looks like some loss at the upload server and at the last hop.

---

is there anyway to encript the transactions so they aren't blocked???

---

WHERE ARE THE FISH????????????????????????????
Meow.

---

"Time is simply the mechanism that keeps everything from happening all at once."

WHERE ARE THE FISH????????????????????????????
Meow.

here.

---

... One of the raid arrays on thumper lost a drive...

you guys seem to loose way to many drives! how many do you have?



anybody got work?

Yes, all my machines are uploading, reporting, & downloading work in a fashion that is reminiscent of a backlog. Some results upload, some fail, backoff kicks in, results uploads after backoff expires, or they don't and it tries again.

Just glancing at the bandwidth chart. It shows that whatever issue was going on didn't really recover until the 18th between 9-10am. So having to recover from an extend outage/slow traffic of about 3 days, along with there being a meltdown in the sever closet, & some server drives going out. I think the recovery is going along nicely.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Users\Eric>pathping 208.68.240.16 bonic2.ssl.berkeley.edu
Unable to resolve target system name bonic2.ssl.berkeley.edu.

C:\Users\Eric>pathping 208.68.240.16 boinc2.ssl.berkeley.edu

Tracing route to boinc2.ssl.berkeley.edu [208.68.240.18]
over a maximum of 30 hops:
  0  DV7-1023CL [66.182.x.x]
  1  cab1-1.1scom.net [66.182.192.1]
  2  DSL2-25.1scom.net [66.182.213.25]
  3  Texas-Independent-Energy6328-custidna.cust-rtr.swbell.net [151.164.76.189]

  4  bb2-p7-1.rcsntx.sbcglobal.net [151.164.190.248]
  5  ppp-151-164-52-74.rcsntx.swbell.net [151.164.52.74]
  6  asn6939-he.eqdltx.sbcglobal.net [151.164.89.34]
  7  10gigabitethernet1-2.core1.lax1.he.net [72.52.92.57]
  8  10gigabitethernet1-3.core1.pao1.he.net [72.52.92.21]
  9  64.71.140.42
 10  208.68.243.254
 11  boinc2.ssl.berkeley.edu [208.68.240.18]

Computing statistics for 275 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           DV7-1023CL [66.182.x.x]
                                0/ 100 =  0%   |
  1   11ms     0/ 100 =  0%     0/ 100 =  0%  cab1-1.1scom.net [66.182.192.1]
                                0/ 100 =  0%   |
  2   14ms     0/ 100 =  0%     0/ 100 =  0%  DSL2-25.1scom.net [66.182.213.25]
                                0/ 100 =  0%   |
  3   12ms     0/ 100 =  0%     0/ 100 =  0%  Texas-Independent-Energy6328-custidna.cust-rtr.swbell.net [151.164.76.189]
                                0/ 100 =  0%   |
  4  ---     100/ 100 =100%   100/ 100 =100%  bb2-p7-1.rcsntx.sbcglobal.net [151.164.190.248]
                                0/ 100 =  0%   |
  5  ---     100/ 100 =100%   100/ 100 =100%  ppp-151-164-52-74.rcsntx.swbell.net [151.164.52.74]
                                0/ 100 =  0%   |
  6   14ms     0/ 100 =  0%     0/ 100 =  0%  asn6939-he.eqdltx.sbcglobal.net [151.164.89.34]
                                0/ 100 =  0%   |
  7   49ms     0/ 100 =  0%     0/ 100 =  0%  10gigabitethernet1-2.core1.lax1.he.net [72.52.92.57]
                                0/ 100 =  0%   |
  8   57ms     0/ 100 =  0%     0/ 100 =  0%  10gigabitethernet1-3.core1.pao1.he.net [72.52.92.21]
                                0/ 100 =  0%   |
  9   59ms     0/ 100 =  0%     0/ 100 =  0%  64.71.140.42
                                8/ 100 =  8%   |
 10   63ms     8/ 100 =  8%     0/ 100 =  0%  208.68.243.254
                                6/ 100 =  6%   |
 11   63ms    14/ 100 = 14%     0/ 100 =  0%  boinc2.ssl.berkeley.edu [208.68.240.18]

Trace complete.

C:\Users\Eric>

i tried from my laptop directly connected to my freshly rebooted modem, no change. i wonder if something has been changed on the WWW...

---

WHERE ARE THE FISH????????????????????????????
Meow.

here.

Thanks Ned........a little injection of humor always helps.

Really.

---

"Time is simply the mechanism that keeps everything from happening all at once."

i tried from my laptop directly connected to my freshly rebooted modem, no change. i wonder if something has been changed on the WWW...

Yes.....something has changed. The dog don't hunt no more.

And the kitties can't find their fish.

---

"Time is simply the mechanism that keeps everything from happening all at once."