The Truth About SETI@Home

zealot writes "According to this article, the SETI@Home project is not using the most optimized clients available "just to brake the unit turn around" so that they can continue to recieve various contributions. The authors are also demanding access to the client source (and asking to GPL it if possible), so the greatest performance may be obtained. " It's an interesting point: They didn't figure on getting the reponse they did, and will sooner rather then later run out of blocks to be crunched. Yep: What happens if hold a war and /everyone/ comes? Or a distributed program, I guess.

They need to set up a parallel splitting project

All of the evidence points to exactly the problem that the author describes. Seti@home needs to write a second client to handle the division of work and "graduate" some of the reliable, high performing volunteers into producing the units of work for others.

Their fundamental problem is that they only distributed the analysis portion. Now that the overall load has become unbalanced, they need to distribute one more piece of the workload.

Proof?

Am I missing something? Where is the proof behind these assertions? It seems that they're extrapolating S@H's reluctance to hand over the source code on demand into a conspiracy theory.

I'm not saying that this is unbelievable, just that it would be nice to have some evidence to back these claims up... or else state them as conjecture, not fact.
--

play nice

Let's not get too wound up because SETI@HOME is getting overwhelmed. It means that the idea is successful. Why do people participate in these kind of distributed processing projects? With the exception of those who want to show off their machine, most of us do it because we feel that instead of our computer downloading Warez or porn all night, we can do something useful.

If SETI@HOME is having some troubles, helpful advice, not scathing criticism is what is needed.

I would much rather see more of this kind of thing, even if it was occasionally bungled, than other groups being scared off because of how hostile the online community is

Maybe I'll find ET...

Yahoo Chat and some comments

There will be a Yahoo! Chat Event devoted to SETI@home from 5 to 7 PM (PST) this Friday 7/30/1999. Go here [yahoo.com] for details.

From the Yahoo page:

Dr. David P. Anderson, Project Director and Dr. Dan Werthimer, Chief Scientist, of the SETI@Home project discuss their perspectives regarding this exciting new approach to computing.

Looks like anyone interested can find out the real scoop from the horses mouth.

The article seemed to be flame bait to me. They never said that Seti@home said anything other detailing the performance critical routine in the seti@home software. Then the way I read it seti@home did not want to give up their source. The article said:

SETI is not interested in receiving a faster client software

Is this what they said or more likely an interpertation of what they said?

Lets check the facts before slamming Seti@Home.

Check out the Lance Armstrong Foundation [laf.org]

my .02 seconds of processing time on this...

I have trouble with any whiney article that has crap like this in it:

"You've bit your teeth and let your box run all night because it took so long to get a unit out, right? But it is for a good cause, so you took the noise, the extra warmth in a summer night and the higher electricity bill. Well, surprise, if you had the proper client software you could have switched the damn thing off at night!"

Oh damn, the Seti@HOME people are "making" me run my computer all night (at "full throtle", no less ! ;-), depriving me of my daily shutdown and boot-up process that every Unix admin just can't wait for!

My opinion of his opinion: he should "get over it". The only thing driving that dude is competition with others, not the altruistic donation of *spare* computing power towards (an arguably) good cause.

If I ever write an article like that, remind me to switch to decaffinated coke.

-adam a

(Re:What Else can we distribute?) Spidering.

Look at the awful job most of the search engines are doing keeping up with the web. Why not a distributed spidering project? Hand out a base of URLs to spider, then let remotes spider from there. As the ever pessimistic Rob has already pointed out to me, the load on the host end would be huge, but I still think if it were done right, the whole net could be cataloged in a few months, then kept updated.

It seems like a distributed spidering project with a search engine front end like Google on different hardware/net could make a search engine useful again. There are probably a few interesting things that sites could do to streamline the workload--I haven't thought of them, but my spidie senses are tingling.

Re:Proof?

Well, good - its not just me that had this reaction as well. I mean really, this was all speculation. It could very well be that seti is concentrating more on how to cope with the 10x volunteers they got (if they expected 100,000 and got a million) than optimizing the clients. But, they didn't say so, directly or otherwise. Whare's the proof?

Besides, what real purpose does it serve to spend any time doing 3dnow optimization of the seti clients when there are more volunteers than they can handle now anyway? I didn't get the point of this article (assuming the premise is true) as to how this would help anyone but the 3dnow bunch. Sure, they have a worthy cause, I would love to have 3dnow in more applications for my AMD, but I don't get how this does that, or how it helps seti.

To be honest, it makes 3dnow.org look a lot less credible than it attempts to make seti look (IMHO).

Re:Huh?

Seems to me the simple answer is to process all blocks twice and compare the results. This would then solve/detect the problem where a hacked client was sending back "untrue" results. Anything that comes back with "different" results gets sent to a third "validated" respondent and the differing on of the initial pair gets demoted from validated. This also solves the workload bottleneck for the time being.

Re:Optimisations/Hacked Clients

Well, if they've got so many more volunteers than are strictly necessary, why not hand out blocks multiple times and check that all the clients give the same results? If you detect any differences, run that block on a trusted machine at SETI@Home HQ and ban the clients that returned the bogus blocks.

Granted, you aren't going to be able to detect hacked clients returning unchecked blocks very easily this way, because you won't have too many positive blocks to compare the results with. But you could seed the raw data with some known positive blocks to catch clients that are returning incorrect (unchecked) negative results. And if a hacked client is sophisticated enough to return a positive result for a positive block and a negative result for all other blocks, isn't that the same behavior as an unmodified client?

Yes, this extra redundancy would slow the project down, but it sounds like there is more than enough computing power available. If SETI@Home explained that redundant processing was necessary to ensure valid results, I'm sure most users wouldn't have a problem with it. If you're interested in SETI@Home in the first place, you already know that good science and/or good data analysis isn't done overnight and requires a lot of procedural safeguards to get the right results.

SETI@Home vs. Distributed.Net

Wouldn't it be interesting if SETI finally recieves an alien transmission, and it's RC5-encrypted? (:

It's just like Linux vs. BSD.. Each side has something they excel at, and something that they lag behind at. Just use whichever one makes you happy.

Re:Now this is a hell of an idea...

This is a situation where a hierarchical workload distribution would probably work. Unlike the SETI project with its huge, monolithic data chunks, a spidering project would be dealing with small (comparatively speaking) chunks. There could be several levels of capability depending on host speed, storage, bandwidth, etc. A company with Suns, a few Gig to spare, and a T3 could handle more volume and complexity--maybe spending their cycles figuring out relevance by context and links, etc., rather than spidering. A lot of the grunt work could be done before the cataloged data are returned to the destination hosts. This would also be a little nicer to bandwidth, I guess.