• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

SETI server problem

Jerboy

Banned
It is about 7AM(EST) and I have not been able to connect to SETI@Home server at Berkerly for the past few hours. Is it just me or are there some server issues?
 
Looks like the server is down. Hope you have some WU's cached. If not, look into caching WU's for this very situation.

-baz
 
This is posted at the top of their homepage 🙁


<< NOTE: Due to a sudden increase in outgoing bandwidth from the entire UC Berkeley campus, the traffic from our network has been capped at a level greatly below our normal operating levels. Please bear with us until campus bandwidth levels come back down to earth. >>

 
Yes, taking a look on the network-graphs starting on http://fragment1.berkeley.edu/~cricket

we'll find Seti under Offsite: inr-60 (SSL) From the graph here they hit 60 Mbits a short while, before falling down to 15-20 Mbits. The normal continuous usage are 26-30...

If I'm not completely off, the external internet-connection is atm1_1_0 under inr-new-666 TEAnet (CalREN2 ISP). From this graph, they have daily hit the limit of 100MBits/s from 17.01.2002.
 


<< Yes, taking a look on the network-graphs starting on http://fragment1.berkeley.edu/~cricket

we'll find Seti under Offsite: inr-60 (SSL) From the graph here they hit 60 Mbits a short while, before falling down to 15-20 Mbits. The normal continuous usage are 26-30...

If I'm not completely off, the external internet-connection is atm1_1_0 under inr-new-666 TEAnet (CalREN2 ISP). From this graph, they have daily hit the limit of 100MBits/s from 17.01.2002.
>>




I didn't see the head note when I started having problems. This reminds me of when Napster first took off. People started sharing mp3's like no tomorrow and it literally flooded the university network and many had to block the port used by Napster.

Isn't this a problem that can be solved by blocking Morpheus, Gnucleus, WinMX and Audiogalaxy from all university computers?
 
I was actually able to pick up and transmit 1 WU around 3:00PM thankfully
but, I could not transfer the other two...still down! 🙁
 
That utilization is Network not CPU.

Since Seti isn't Network intensive they must be running SETI. 😉

And Dump at Noon! 😀

 
Actually I think things are getting a bit better. My two workhorses transmitted 2 and 3 WUs and picked up replacements. 😀
 
Mine all posted overnight (between 3am - 4am EST) and my queue refilled.

This was anticipated by many of us when they officially decided to change the 3.00 client to explicitly slow down WU returns and save bandwidth (and IMHO, to hell with the science), rather than come up with a more permanent solution for reducing the network load. Progress dictates that CPUs will continue to run faster and faster and thus the WU times and times between uploads WILL drop, causing overloads during specific times of the day.

Back when the 3.03 client was first announced and the fact that it would "double the drift rate" (and WU times) to be scanned, a number of people from various corporations offerred to become mirror sites for WU distribution so that client interactions on the Berkeley campus could be reduced. Others suggested that official mirror sites be setup around the world (eg., at Universities) to help out with WU distribution, and then the results at those remote sites could be transferred directly to Berkeley from the specific mirror servers, rather than have individual clients and/or queues doing that via hundreds of thousands of individual machines. All of these offers were ignored and the whole thing was conveniently swept under the rug.

So now, here we are... Rapidly closing in on the same situation that we were in before 3.03, repeating history once again, despite reminding the Project controllers of the risk of bandaid fixes. But what's worse this time around, is the fact that SETI@Home's bandwidth has been capped, whereas previously when we hit this point, the pipe was 3 times as big, and the saturation of that full pipe was what forced SETI@Home into being capped in the first place.

Let's see if they'll be intransigent once again and double the WU times without considering alternatives. I expect they would... :|
 
My central cache is set to dump at 1-2AM Eastern time. Seems like all 20-30 results got off fine. The list of waiting WUs looks good as well (over 200🙂 )
 
Back
Top