• 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.

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

Orange Kid

Orange Kid

Elite Member
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
 
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.

 
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!
 
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.
Click to expand...

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.

 
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.
Click to expand...

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.
Click to expand...

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.
 
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
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top