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

Comments

Article in March '02 _Scientific American_

[Black Parrot]

Possibly of related interest, the is an article on Internet Scale Operating Systems in the newest Scientific American.

Scaleability

[WndrBr3d]

You have to give the Set@Home Team their props for making a system thats scaleable and able to handle the user load from the first 100,000 users to the now 3,000,000.

I've always believed the bottleneck in Distributed Computing was the Data Packets being sent/recieved because the demand will grow exponentially the more users you aquire.

Most applications seem to remidy this problem by limiting the data packet sizes from 5 - 15k compressed packets. This has worked for projects like Distributed.net.

I can only forsee the future of this problem being the same that plagues Video Card Chipsets, which is insted of re-engineering the device to make a more robust and lower overhead solution, they'll just throw a bigger pipe on the line (much like Memory Bandwidth demand).

But again, my respect goes out to the Seti@Home team and their sponsors for architecting a technological data mining marvel.

Necessity is the mother of invention

[m_evanchik]

In a way, this hurdle could prove a boon, by forcing the SETI@home developers to make their system more efficient.

Necessity is, after all, the mother of invention.

As their own statement points out, two of the short-term solutions include making the data sent out more efficient (binary instead of text) and letting each node do more computation.

SETI@home was originally developed to male up for the shortcomings of processing power of any single computer. To solve the problem, they took a bit of a free ride on networking bandwidth to distribute the problem.

Now their success is also forcing them to be more efficient when it comes to network bandwidth, as well as processor, utilization.

So this forced economy will hopefully make the system more efficient through improvement of the system.

Pie-in-the-sky and we have all the computing power and bandwidth we need, but then who would have an incentive to innovate?

Ultimately, SETI@home's legacy will probably have less to do with discoveries of extraterrestrial intelligence and more to do with the evolution of better computing techniques!

Simple elegant, and wrong

[xenocide2]

Unfortunatly, Berkley has two pipes, one for the Residence halls and one for the rest of campus. It seems odd that they can't figure out where all the data is coming from, but I don't think its students in the dorms. Its possible that someone is running a public proxy or an ftp on their dept. network, but you'd think a renowned computer school like Berkley could afford staff and software that could figure the simple stuff out.

p2p (Morpheus, Gnutella) the culprit?

[mactari]

The one thing that interested me about the blurb from the Seti@Home site that was linked from this article was the following quote:

> But starting last month (January 2002) the
> bandwidth used by the rest of campus increased in
> an unexpected and unexplained way.

I wonder if this isn't a byproduct of the intense bandwidth issues associated with peer to peer apps like Gnutella and Morpheus, popular music "sharing" applications that seem to get a bit of use on college grounds nationwide. I'd guess (if I had to; definitely talking out ye old arse here) the reason bandwidth usage wasn't noticed sooner is that many places (my place of work included -- I'm a gov't contractor) are placing a pretty high priority on "Homeland Security", including taking a fresh look at internet usage.

These things aren't exactly bandwidth friendly (see http://people.cs.uchicago.edu/~matei/PAPERS/gnutel la-rc.pdf for a great discussion on the perils of the flaws in the first generation Gnutella protocol).

Anyhow, that's what came to mind when I read the blurb. I think their best short term solution might be to chase down unattended Gnutella and Morpheus/KaZaA applications and get back that bandwidth.

More then one...

[Wiwi Jumbo]

I'm currently trying to run Seti@Home and the UD Cancer Cure program but it's not going well... Seti won't give up any cycles to UD.... and in light of this I'll be shutting down Seti for a while.

But what I really wish was created was a single program which all other tasks of this nature could be setup as plug-in's.... each plug-in getting all the unused cycles until it completes a unit and then the next plug-in get's it's turn... maybe even be able to decide how you want to skew the processings:

5 Seti@ Home units, then 12 UD units, 4 Folding@Home, etc....

There are a lot of projects out there I'd like to help with.... if only they'd play nice...

Different Provider

[cdn_Gfunk]

this may sound funny if you can't raise money at $300 dollars per megabit but ever think of using a provider like cogent you could be provisioned a 100Mbps cat5 link for $3000 per month and use all you want. Just a thought