###ATTENTION USERS OF ORANGEKID"S SETIQ###

[Orange Kid]

I have moved the overload of work units that need to be uploaded to Berkeley to a different Q.
This one is not a public viewable one
It will hopefully enable it to accomplish this task a bit timelier and allow the usual Q to work in a normal manner.

NO WORK WILL BE LOST

This just allows this Q to get the wu's uploaded and save all the looking at it to interfere with trying to upload



EDIT::::::: As of 2:25 CST all the backlog has been uploaded

 

[Shuxclams]

Thanks OK, Reminder to users that there arealos regional SETIQ's that can handle your Work Units during this time. Look Here for the list of Q's













SHUX

 

[onebadv6]

Agreed. I set up mine just because of last time we had these problems. Sofar no takers and still poor OK's Q gets hammered.

There are may Q's out there as shuxclams has stated. We need to be running our own Q's or making sure to distribute the load to the other servers so that we don't have these major backloads. With the attack on the internet just last weekend and the posibility of more copycat type attacks we really need to put our eggs in other baskets. God forbid any Hard drive failures on the popular Q's.

 

[titanmiller]

Thanks for the news!!!!!!! I was getting nervous that my work would be lost. My mind is now clear.

 

[soni]

seti.soni.dk:5517 is running on RAID 1

 

[titanmiller]

Isn't the reason that it became overloaded is because the main Seti@home data server was dropping connections, not because of insufficant bandwidth on your (OK) part.

Edit: All of my WUs are now up, thanks for transfering them OK!

 

[Wellcky]

/me wonders when the sever will go poof! < insert cloud of smoke here >

 

[onebadv6]

Isn't the reason that it became overloaded is because the main Seti@home data server was dropping connections, not because of insufficant bandwidth on your (OK) part.

Correct. This was Seti@home's fault and lack of bandwidth not OK's fault. But the way I visualize it Seti at home has a small connection pipe and OK's big pile of completed WU was just too large for the pipe. But the smaller Q's had less backlog due to fewer units tying to get down the pipe.

 

[Wiz]

Thanks OK - I appreciate the extra effort

 

[titanmiller]

Originally posted by: onebadv6

Isn't the reason that it became overloaded is because the main Seti@home data server was dropping connections, not because of insufficant bandwidth on your (OK) part.

Correct. This was Seti@home's fault and lack of bandwidth not OK's fault. But the way I visualize it Seti at home has a small connection pipe and OK's big pile of completed WU was just too large for the pipe. But the smaller Q's had less backlog due to fewer units tying to get down the pipe.

Acctually if I remember correctly the data server was recently hooked up to a 100mbit connection to the net. It's not a problem with bandwidth rather a problem with being able to connect.

 

[Smoke]

Would you all quit mentioning "hard drive crashes". :|

 

[Confused]

Another way to think of it is like this:

If SQ can't connect, it waits for a set time, up to the max set in config (most people change this to 10, the lowest it will go). If you have one Q, it will only try to connect once every 10 mins, and will wait a set period of time between sending/recieving each unit.

If you have multiple queues, they can all try to connect at the same time, and send/recieve more in the same period of time as one individual queue can, once it starts accepting connections again




Confused