<< if you have a queue running or use another queue with less traffic, the bandwidth problem ain't that bad after all. >>
That is not true for all of us as the past two days I've had a lot of trouble. I stopped sending my stuff to OK's site to ease his load a little bit. For the first week I was able get my stuff through to SETI with little problem. It would take me about 2 hours on dialup. Yesterday I was able to flush all my WUs, but it didn't refill the Queue completely. Well, this morning it ran for four hours and I still had 47 WUs to upload and was able to get only 15~20 WUs downloaded.
When this problem first started, many of the queues backed up that week, but were able to get caught up over the weekend. Since then the weekends have not been any better than the rest of the week. I really wonder if SETI has reached critical mass!?! Can they fix it and will they?
Here is what SETI says about it:
Short-term solutions We're working on several short-term solutions:
o Increase the bandwidth of UCB's network connection. We hope to "expand the pipe" by about 10 Mbps - enough to ease, but not eliminate, the crisis. The issue is money - bandwidth costs about $300 a month per megabit, and neither SETI@home nor the university has budgeted for this cost.
o Send data more efficiently. Currently work units are encoded as text. By sending them in binary, we can shrink them by about 25%. (Note: data compression isn't effective for our data, which is primarily random noise). This change will require a new version of the client software.
o Increase the amount of computation per work unit. Doubling the CPU time per work unit - by looking at more chirp rates, for example - will reduce bandwidth by 50%. There is scientific justification for doing this, although the law of diminishing returns applies. This will also require a new version of the client software. (This is what many of us are afraid will happen as it did in Jan 01.)
Long-term solutions
The long-term solution is to allow work units to be sent from servers outside UC Berkeley. This could be done, for example, by sending work units to servers at organizations - companies and universities - that are willing to donate part of their outgoing network bandwidth to SETI@home. In addition to solving the current problem, this could greatly increase our overall data capacity, enabling us to search for ET signals in a wider frequency band.
This solution represents a significant change to our software; we will use this approach in our next-generation software. We are seeking funding to develop this software, and it won't be ready for at least 6 months.
Facebook
Twitter