Slashdot Mirror
Seti@Home Bandwidth Problems
reflexreaction writes: "With so many of the /. users actively using and supporting Seti@home, many of you have realized that in the last couple of weeks that Seti has had some serious problems receiving completed data and getting new data to process from its 3 million members because of network bandwidth problems. All the gritty details are here. The article details some things that users can do to alleviate some of the problems including connecting during off hours and downloading more than unit than once using programs like SetiQueue for PC and Seti Unit Manager for Mac. Donations are also accepted. There is also a plea for bandwidth donations. It will be truly unfortunate if this page becomes /.ted without benefit from /. users."
2/6/2002
The problem
When your SETI@home screensaver downloads a work unit, the data flows from a server in our laboratory, through the University of California at Berkeley campus network, and through a connection to the commercial Internet. This connection is shared by all UCB Internet users - departmental web and FTP sites, email, SETI@home, and so on. The University pays for bandwidth on this connection; it is currently buying 70 megabits per second (Mbps). The student residence hall have a separate 40 Mbps connection.
Until recently, SETI@home was given about 25 Mbps, and the remaining 45 Mbps was shared by the rest of campus. But starting last month (January 2002) the bandwidth used by the rest of campus increased in an unexpected and unexplained way. During peak periods the demand now exceeds 70 Mbps. If SETI@home continued to use 25 Mbps, the performance of all other outgoing traffic would suffer.
The UCB network administrators have worked hard to balance the bandwidth needs of SETI@home and the rest of campus. Currently, SETI@home traffic is given lower priority than other traffic. During peak periods (typically 10 AM - 10 PM PST) SETI@home averages 6 Mbps, and sometimes gets no bandwidth. During non-peak periods SETI@home gets as much as 50 Mbps.
When SETI@home is not getting enough bandwidth, our data server backs up - all of its processes are waiting to send data, and it can't accept new connections. During these periods, your screensaver will get report that it "can't connect to server".
The impact on our overall computing rate is significant but not too serious - the rate has dropped about 25%. But many SETI@home users are unhappy that their computers are sitting idle for many hours, waiting for data. We share this unhappiness, and are working to solve the problem.
Short-term solutions
We're working on several short-term solutions:
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.
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. 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. 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.
What you can do There are a couple of things you can do to keep your computers busy processing SETI@home data:
If you connect manually (e.g., over a modem) try connecting during off hours (23:00 to 3:00 Pacific Standard Time, or 7:00 to 11:00 UT). You can check the Server status page to see if we're currently dropping connections. Download more than one work unit when you connect. This can be done manually, or by automated workunit caching software. Example programs include SetiQueue for Windows, or Seti Unit Manager for Macintosh. For more information about other SETI@home add-ons see our links page.
To help us achieve a short-term solution, you can help in two ways:
Donate to SETI@home. This will enable us to buy network bandwidth. Help us find "bandwidth sponsors". We hope that a major commercial ISP might donate bandwidth to UC Berkeley to help SETI@home. If you work for, or have contacts in, such a company, please contact us.
About the current bandwidth problems
I second that. Not that one is necessarily more useful than the other but perhaps there should be more... distrobution... of computing power to different causes. United Devices seems to be a worthy alternative to SETI@Home.
Despite the fact that nothing new has come out of distributed.net for a while now, it's still the best-run distributed computing network. They have the most clients, for the most platforms with the most features, and that's why I continue to install the client on several PCs a month.
I've used SETI@Home and United Devices before, but frankly, I didn't like them much.
SETI has more users than it needs, last time I checked, the same data was being tested over and over again, simply because they have more volunteers than they need. I'd much rather see that CPU time go to the projects that need it.
United Devices has an admirable goal, curing cancer, but a lack of SMP support in their clients, and the lack of a Linux or Mac client pretty much rules them out for me. I use Windows, Linux, and Mac OS X every day, I can't run United Devices on all those platforms...
So come on everybody that's running SETI, save them some bandwidth, come join distributed.net, and we can power through the rest of RC5-64!!!
Just don't get me started on the OGR projects, they've been open for too long, and no one seems to know how to close them. OGR-24 should have been done a long time ago, but isn't, due (apparently) to a lack of managerial oversight, or poor planning.
When in danger or in doubt, run in circles, scream and shout. --Robert A. Heinlein
I would have expected UC Berkeley to have a higher bandwidth connection to the Internet.
Internet2's goal is 1Tbps connections -- That's faster than 70Mbps by over 10^5. Pretty funny.
Seriously - I shut off all my machines seti@home search and my electric bill dropped 10$ and I'm not kidding anyone in the slightest.
What is the point anyhow? I mean this is collectively costing them (probably) billions of dollars a month to do this - between everyone's increased power bill. And seriously - what are the chances that their algorithm are going to find something worthwhile?
Why even bother their servers at all? SETI should wait until we have our own world's problems figured out. Please visit Folding@Home or Genome@Home for two ways you can help solve actual problems. If solving geeky problems is more your style, visit d.net.
Go, do it now, I swear you'll feel all warm and fuzzy.
Sure, it supports mulitple processors.. Just use a program like SetiDriver, and you can tell it how many WorkUnits you want to crunch simultaneously. Though the client really is optimized for intel processors for the most part.
To quote: "SetiQueue for PC and Seti Unit Manager for Mac."
Please... guys... as an author (read: someone with a vested interest in the English language) and a long-time major geek, I am really irked by this sort of thing. I have come to expect that newbie-types can and almost always will confuse the terms "Mac OS" and "Mac", and the terms "Windows" and "PC", but this is SlashDot.
I don't mean to be ridiculously anal here, but I do wish to stick up for correct usage of technical terms and names. "Mac" and "PC" are hardware architectures. Unless your copy of SetiWhatzit is written to actually be its own BOOTLOADER (that is, unless it IS the operating system), you do not write it for the hardware. You write it for the operating system.
Mac OS is written for the Mac.
Kaleidoscope, Fetch, Office '98, Apple/Clarisworks, etc. are written for Mac OS.
Windows is written for the PC.
(insert name of any given Windows program) is written for Windows.
The OS sits atop the hardware and the programs sit atop the OS. Therefore it is incorrect to say something like "This-or-that program for Mac, and that-or-this program for PC".
To illustrate just how this is blatantly incorrect (and I am not really just being nitpicky after all)-- consider this one:
The program cited in this story as being for "PC", would not run on MY PC, despite the fact that it is a perfectly decent, high-quality PC. Why? Simple-- it runs Linux. This program isn't really for the "PC" at all! It is for Windows. Big difference.
The program cited in this story as being for "Mac" would not run on many Macs I have owned in the past. Why? Since my Macs also ran Linux. And occasionally NetBSD. Perfectly good Macs, but they didn't run Mac OS. This program, likewise, is not for the "Mac". It is for Mac OS. Also a big difference.
I don't like having to dredge up this sort of nitpicky nonsense, but honestly, people, we're SlashDot. We should know that not every "PC" runs Windows, and not every "Mac" runs Mac OS. If any population should know this, it's us.
As a proud user of Debian GNU/Linux on both the PC and Mac (68K and PowerPC) platforms, I am very upset that people are further minimizing any and all alternative operating systems (and encouraging people to think that Microsoft and Apple are all that exists) by saying "for PC" when they mean "for Windows", and "for the Mac" when they mean "for Mac OS". Please, let's refrain from this sort of misleading? We may not be able to stop the slow monopolization of all things digital, but we sure as heck can at least try to slow its progress a tiny bit by promoting technical knowledge and understanding of computer terminology.
--Jessica
------------------------------------------- Just Say no to Windows!
This presentation from the Berkeley network admin (Ken Lindahl) shows exactly how the BW has increased, and the problems they encountered in rate-limiting traffic.
In fact, more presentations about the BW problem at serveral universities is here. They'd like to use traffic shapers, but traffic shapers are only designed to handle T1-level traffic, not OC3-level traffic.
I saw the presentations in person (and I'm from Berkeley). They don't want to get in the business of deciding what is valid traffic, nor investing time to block the various workarounds (e.g., HTML proxies) that people will use to get around the filters.
A temporary solution is to use proxies at other campuses to send the traffic to Berkeley via Internet2, since that traffic is free and isn't being restricted at Berkeley.
Time for SETI@Home to take a page out of the Dnet book. Let the client cache multiple blocks. Have the client contact the server before it runs out of data and schedule a time to retrieve more blocks.
Simple.
UCB net admins and other interested parties have been discussing how to deal with the increased bandwidth demand on the ucb.net.discussion newsgroup: Google Groups thread: "latency from off-campus".
I live across the street from the Berkeley CS building where half the EECS servers are housed, and my connection to those machines can get pretty lagged. Having an inconsistent ISP certainly exacerbates the situation, but my experience with off-campus latencies has been quite bad for the past two years.
Sure it's sad that Seti@home users can't use their computer's idle cycles quite so effortlessly anymore, but the bigger picture is that everyone trying to connect off-campus is suffering, especially people who are trying to get work done.
The surprising thing for me is that detaching the dorm network (with all the student-run servers) leaves very few computers that could be sucking up all the bandwidth. We've suffered through DoS attacks from time to time, but the fact that Kazaa is still the number one bandwidth hog makes me wonder who runs these apps (professors? grad students? janitors?) and where are they running them from (lab computers aren't the best places to store all that warez, mp3s, and divx files, unless you don't care that they all get erased every day).
The residence halls have a separate 40Mbps pipe, so it is 110Mbps combined. Also UC Berkeley conntects to Calren-2 and Internet-2 which run at much higher speeds but the problem with those is that they connect to large universities only.
CalREN-2 consists of two giant loops - called CalREN North serving UC berkley and CalREN South (in the Los Angeles area). Each loop is a gigaPOP - providing the high-speed connection into the nationwide Internet. Each loop provides OC-48 (2,448 Mbp/s) connections to member campuses.
Now, since this equipment has been in place since the middle of last summer, Why are they using their dual 45Mb/s connection? Just get some cable dogs out there to run some fiber. Hell, I'll get out there and run some fiber for them. Remember when some yahoo's cut their fiber while stealing copper to recycle? They were down for like two weeks. Well, it took them two weeks to run fiber across the campus again. If they get started now, they could have as much bandwidth as they could possible want by running fiber to their Internet 2 pop.
I have seen the I2 Pop at the Sonoma county office of education. It is running at OC-3 (155Mb/s). That means a bunch of elementary schools have twice the bandwidth as the most prestigious Computer Science program currently running in the world. Prestigious? Yes, they have effectively harnessed millions of desktops to create the fastest computer on the planet by a huge margin. They push 27 Tflop/s on 25 Mb/s compared to ASCI White that just passed 10 Tflop/s. My computers, like every body else's, have wasted a lot of cycles waiting for data. Imagine if they had 2,448 Mbp/s available to them and enough users to create the first 2+ giga-flops computer. Of course they would need 240 million users to achieve that.
Just to be a pessimist, that is probably exactly what all the distributed modules in Win2K/XP are for. Bill is going to have a really nice computer one of these days.
If voting were effective, it would be illegal by now.
This wasn't very hard to see coming, but its still unfortunate.
For those who are looking for a workunit-caching program for linux, I've written a perlscript which has done a quite good job at it. I've decided to release it tonight, to help everyone out, but its a bit rough on the edges. It does the job, though. Read the README, download it here. Also, mirrors are welcome - my connection sucks far worse than theirs does =)
Paranoid
Bwaahahahahaa.
A great site that lists nearly all distributed projects + news about them: http://www.aspenleaf.com/distributed/