Suggestion to help OK's queue

[zeruty]

My personal queue seems to not be having much problem uploading directly to berkeley
I was thinking that if some people with personal queues and other public team queues would allow OK to upload maybe a couple hundred workunits to their queues, this would help OK's queue out quite a bit.. I wouldnt mind having OK send a few hundred to my queue (seti.deception.net:5517), and letting my queue upload them from there
also OK, just so you know.. I've decided to take my queue off of yours now, I can do ok going directly to berkeley and I don't want to add any fuel to the fire at your queue
feel free to redistribute the wu's in my queue(on your queue) to other queues that are running low

 

[RaySun2Be]

I don't have a public Q, but I did point both the work & home Qs directly to Berkeley, and they seem to be flushing/fetching without a problem. Not that there are that many WUs, 25 at work, 13 at home per day.

 

[Shuxclams]

What connection settings are you using and how do I point at you zeruty?













SHUX

 

[zeruty]

what do you want to do? upload some to me?
I used pretty much default settings I think, what do you need to know?

 

[Shuxclams]

If you think you can flush 200 Wu's for me that would be great... But how do I point my Q at yours?













SHUX

 

[MaxSiren]

I'm pretty sure that we're all on equal footing when it comes to this latest bandwidth shortage, so I doubt that one Q will have any better luck connecting than another. If it does work however, by all means let us know!

 

[serialb]

I agree with MaxSiren. I didn't have much problem fetch and flush until yesterday when everything seemed to come to a halt.

Shux, to point your queue to another, you have to set the connection type from Default WinINet to WinINet Proxy under server settings. Then enter the IP and port of the queue you want to point to.

 

[Confused]

I am willing to take a few people on my queue, teamanandtech.d2g.com port 80.

Also, if people who can change where their queues or own clients point to, please choose a proxy from this list to relieve the strain on OK.

ConfusedBW

 

[zeruty]

<< I'm pretty sure that we're all on equal footing when it comes to this latest bandwidth shortage, so I doubt that one Q will have any better luck connecting than another. If it does work however, by all means let us know! >>



well one queue sending in 200 will take longer than 2 queues sending in 100 each, I would presume...

 

[Shuxclams]

For the people who have uploaded results to the scarieville Q, there are Wu's moved into your accounts.













SHUX

 

[ChuckWits]

Wouldn't there be an overall negative effect to the bandwidth situation if lots of folks installed and started using SetiQueue though? Somehow it seems as though that would just increase the amount of bandwidth necessary rather than just continuing to use existing proxies. Or am I totally wrong about this?

 

[Poof]

Wouldn't there be an overall negative effect to the bandwidth situation if lots of folks installed and started using SetiQueue though? Somehow it seems as though that would just increase the amount of bandwidth necessary rather than just continuing to use existing proxies. Or am I totally wrong about this?

There has been a bit of a debate about this issue on alt.sci.seti. To me, the bottom line is if you don't have a moderate to large-sized farm of crunchers, then having a Setiqueue per machine would sortof be a waste... ALTHOUGH the beauty of Setiqueue is that you can continue crunching but defer (the key word) uploading/downloading to a specific time of theoretically low network usage. Those caching programs (like Setidriver, etc.) that allow the client to control the uploading/downloading, will continue to try to transmit unless manually turned off.

The use of a large queue (or queues) for a team, reduces the number of connections to SETI for work, AND shifts the bandwidth load OFFSITE to the queue's owner. That is, if a team has say 100 members who crunch using 500 machines, it is better to have a single large queue make ONE connection to upload/download for the team once a day, rather than have 500 individual connections happening throughout the day AND actually multiple times during that day if they have faster processors.

Ie., say the average speed of those 500 machines was 500MHz, then we know that a 500Mhz (PIII equivalent) machine can usually do about 2.5 WUs/day. This would mean at least 1500 connection attempts (+/-) would be made to SETI in a 24 hour period from those machines rather than 1 or 2 from a queue flushing/fetching once a day.

 

[ChuckWits]

An excellent reply, Poof...thanks