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.
I would rather see that they not GPL the client. It would be far too valuable under a BSD license or an X Consortium license. Whereas if the software were placed under the GPL the code becomes useless for general use.
They're worried about running out of blocks to process? Isn't that the idea?
I would think it would be good for project morale to say, "Look how good we're doing! We can process the data blocks faster than we receive them!" Seems to me that the purpose of this project is to get something done, to make some progress...Not to keep everybody busy for as long as possible.
Anyone else find that final sentence difficult to understand?
;)
Da grammmur on dis syte is atroshus.
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.
Geeky modern art T-shirts
Opening up the source code to the world will increase the block counts in two ways:
1) Optimisation
2) Hacked clients returning blocks unchecked, as previously seen with distributed.net
By using a hacked client and _lots_ of different
e-mail addresses to report completed blocks with, any hacked-client-antics could go undetected....
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.
--
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...
-------------------------------END--COMMUNICATION
The article in 3DNOW is way off base... If you check the seti@home home page (http://www.setiathome.ssl.berkeley.edu) they explain why the code is not released to the public. Additionally, the code improvements they discuss are limited to Intel chips, and I, for one, am not running the bulk of my setiathome clients on Intel chips (too slow...), although I realize that a good portion of the clients being run are Windoze clients.
I'm sure everyone is already aware of this, but there are 2 clients for windows - one gui based, one console based. The console based one goes about 2 or 3 times faster than the gui based one so anyone interested in drastically increasing their block processing speed can do so immediately by using the console based client. Also, I've seen some really odd stuff over the last month in the seti@home stats ... first MS is substantially behind Team Slashdot, then they suddenly surge ahead, then their numbers *decrease*, then they surge ahead again, then they disappear from the stats page entirely [!], then the return with low numbers, then (today) they're 20K blocks ahead of Team Slashdot - what in the world is going on here?
there are two kinds of people in this world - those who divide people into two groups and those who don't
We're distributing encryption cracking and alien detection. What else can we distribute? We need something that can be broken down into small parts, worked on in parallel, and isn't overly time-sensitve.
We could get some writers, artists, and 3d animators together and make 'the great Net movie', and render it on the largest rendering farm ever.
Maybe some sort of distributed neural network? Dunno.
Ideas?
From the Yahoo page:
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:
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
kayaking
damn it people, isn't the philosophy behind coding very similar to sentence diagramming? shouldn't we be the people who speak correctly? sorry for ranting, but it irritates me to see a group of people so incapable of expressing themselves. not that i'm trashing hemos here... it just comes to a head with him because he posts.
if we're serious about this "revolution" thing, we need to give people a reason to take us seriously. communication is essential... yes, even with the outside world.
i don't really know where this came from, and i beg the moderators to regulate the hell out of it for being off topic.
It sounds like academia is just as fraught with Dilbertisms and idiotic management as industry. With the type of response SETI@Home has received from the world it seems that their problems could be solved with a simple call for help to the community. But it appears that they have not learned anything about community development success open source efforts have had, and are ego-inflated by their monopoly on SETI data and insist on being control freaks. The sad thing about this is that their attitude will eventually affect their ability to get funding, as skeptics can easily point out the fact that when they were donated millions (anyone care to really estimate?) in free computational power they wasted most of it.
/leading/ contributor to the effort, but I am in the top 0.3%-tile overall, and in the top 30 in "team slashdot", having spent a decent amount of time to get the software running autonomously on a handful of SPARCs. But I think now I'm going to look more closely at distributed.net despite the fact that SETI engages the imagination (and fantasy) much more. Anything we can do to improve this process?
I'm by no means a
I chose AMD because I fancied not tossing my motherboard and case. I run on a 450 MHz AMD-K6-2, with the 3d-now! extensions (of course). I can tell you from experience that the FFT that Seti@Home uses routine on an AMD SUCKS. It takes forever to do a single block of data, and I calculated it would eventually take something like 70 hours to complete the block. I was disappointed. Granted the floating-point on AMD's aren't great, but they aren't THAT bad. That was part of AMD's purpose to include 3D-NOW!, to handle floating-point better. The fact that they are unwilling to optimize the code just plain makes me angry. It puts those with alternative processors at a disadvantage, when the users themselves are willing and able to fix it. That is the reason I love RC5: it runs well no moatter what processor you use, it's optimized for almost every one, and if you want to optimize it further, distributed.net allows you too. Just because Seti@Home claims they will run out of blocks of data, it does not matter. If they do, perhaps other programs will see the need to contribute.. perhaps the ACTUAL SETI program.... (this is not actually run by SETI, but by an affiliated group). We could all get a lot more done if we simply all did our best to get what 'needs' to be done done, and worry about the next source for our work when we get there (a la RC5).
(Joke! :))
www.HearMySoulSpeak.com
A simple way to speed up the process would've been to add a simple button to the Win9x version that turns off the graphics - using the 'trick' with the screensaver that turns off the screen already speeds it up dramatically - and I doubt ppl really site in front of their machines for hours and hours to just watch the graphics that the program produces..... I would've been happy with a prog that'd run quietly in the background on Win9x and calculate while I'm online. (Yes, I use Win95 and therefore I can't use the WinNT Commandline version).
The aliens would use hacked clients to hide the approaching mother ship!
1.5 hours per work unit!!!!!
Deleted
The problem is that the work units are created from the Arecibo Radio Observatory, and not many people have their own radio observatory...
/El Niño
I've been recieving ancient Seti@home units for weeks. They keep sending out the same units over and over, from January 1999 through March 1999. When you work on it, you notice that it just keeps looping. You hit a February unit, then a March unit, then a January unit, etc.
:)
Maybe they've set it up to analyse the units in that strange order, but I doubt it seeing as they have enough computing power to encode several thousand years of MP3's per day... using BLADEENC!
What the Seti@home project needs is a way to better manage the data that they're being sent. It would also be nice if they'd optimize their client so we could run it for the same amount of time, but have it take up less CPU. It really is intrusive when it's not running in screensaver-only mode under windows, and without -nice 19 in Unix.
They can't distribute the splitting project because the data blocks are HUGE. I'm guessing that the data comes in large chunks, maybe just one large chunk, even. If they could distribute that, they wouldn't need to, because the blocks would be small enough to send on their own.
---
END OF LINE
Never attribute to malice that which can be adequately explained by stupidity.
Look, this code is unoptimized. We all knew that. No news there. Now, they say they're not currently interested in optimizing it, probably for a couple of reasons. I mean they're having problems keeping up with the current load as is. What's wrong with them wanting to sort that out before they add in the problem of different code bases for various chipsets?
Look, these guys aren't experts in distributed technologies like the guys over at d.net.. Hell, no one's as expert as the guys over at d.net. You can't run d.net for as long as it's been going on and not be experts.
So the seti@home guys can't split the bits up fast enough to avoid duplicates? Well hell, there's hundreds of corporate sponsors falling all over each other to donate stuff, right? Use that!
Frankly, I thought seti@home should've teamed up with d.net from the beginning, instead of trying to setup an entirely new system. Why not use an existing infrastructure? Quite a hell of a lot of people (myself included) killed the rc5 client in order to run the seti@home client. I don't want to go back to rc5, but I don't want to duplicate work either.
Seti@home should just hand the codebase over to the d.net guys and see what they can make of it. If the setup is anything like d.net's, then they surely can help with getting more bits split, as it were. So you got too many people to help? Well, that's what you get for not doing your homework, no cookie for you. Now admit defeat, and get some FREE help.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
Oh damn, the Seti@HOME people are "making" me run my computer all night (at "full throtle", no less !
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
There are several groups that have wanted to send in optimizations but have been told that they cannot use them. I believe that the author of this opinion piece is way off base. It is not that they are trying to slow down the processing, it is that they are trying to control the source code that is in use! they want to avoid having the code fork into 50 different code bases one for each processor/platform. This would become fairly uncontrollable for them very quickly, especially if they encounter a problem that they need to fix, instead of a simple fix for all they would need to do it over for each different code base. (I think that people here can probably see that this is a problem a lot clearer than the masses that just want to see their name/team high on the list and have no idea about what "goes on behind the scenes")
What seti@home needs more than speed is scientific reproduceability this is why they are turning away platform/chip specific performance tuned clients. This guy is looking for a conspiracy that does not exsist. (and making himself look foolish in the process)
*removes Seti@Home off of the three linux boxes, the one OpenBSD box, and the UltraSPARC he had it running on, installs RC5*
--
Dave Brooks (db@amorphous.org)
http://www.amorphous.org
But when my computer is MY work, my, hobby, i don't like it when a program doesn't use it and makes it look like crap....
Hey! Get all your freakin monster machines out of the project. It's not a competetion.
I have a crappy little Cyrix P200 running in screen saver mode a few hours a day. I'm still working on my first block - which all of you power hogs have undoubtedly reworked 3 or 4 times by now.
Give us little guys who are actually interested in the SETI project a chance to really participate.
You never really know how close to the edge you can go until you fall off.
Is there anything out there in the Open Source realm that does this kind of distributed processing stuff. I know that each project is different and needs customized stuff, but a general program would work. Something like the following: :).
Server - program to keep track of all stats send blocks, recieve answers, redundancy checks, a blank area for your own backend stuff, and maybe some HTML reports (cuz everyone wants to see this on the web
Client - basic framework of how to receive problems, send answers. Then have an blank area in the code where people can add in there own stuff as a module.
Licensing might be a problem, but I'd suggest that you leave the individual code as a sperate program thus the cutomized part wouldn't need to be under the GPL if the general part was GPL'd and a company wanted to use it. Maybe the LGPL?
I don't know enough about all this stuff, but everybody seems to like playing with the distributed projects, it would make sense if there was a free version. I know there are arguments against opening the code (easier to fake answers), but couldn't redundant checks help that?
-cpd
is anyone else getting tired of /hemo's/ way of emphazing /stuff/?
Run 8 of them under linux AMD 300 178MB ram with -nice 20, it takes about a week for it to process all units, this is good if you have a dial up line, only have to connect on saturday to upload the results and download some more work units.
Make that, oh, around 20 million entire CDs per day. One CD takes me 15 minutes to rip and encode. They've got 290 kiloclients or so. Work it out. My estimate assumes they aren't working for the entire day. Anyone know how many unique CDs there are total in the world?
---
END OF LINE
Am I the only one sick of seeing this argument used against SETI@Home? This is totally STUPID. My computers would run the same hours with or without SETI@Home on them. I also don't think that I'm pulling *that* much electricity to make a large impact on the atmosphere - and my area uses hydroelectric power anywayz.
I think it's funny though when people hear this argument and then use it to advocate d.net.
Err, distributed.net is not open. The fact that the distributed.net client was hacked demonstrates, once again, that security through obscurity does not work. In other words, trying to make it more difficult to hack the client by only publishing the object code rather than the source code as well is a much worse solution than figuring out some way to guarantee that bad blocks cannot be submitted, regardless of the functionality of the client.
BTW, unless this seems normal, it seems the client may have already been hacked:
62) polle 3975 1193 hr 28 min 43.0 sec 0 hr 18 min 00.9 sec
straight off the top 100 lists just now..
Notice, 18 MINUTES to complete a work unit.. Umm.. no.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
I always thought it would be cool if someone was doing an animated movie like "a bug's life" on a shoestring budget using the net as their render farm. That would be way cooler than encryption cracking or SETI. Of course, the rendering is the easy part, coming up with a decent script, doing all the 3d modelling (coming up with all the frames that need to be rendered), and then there's the audio...It would be tough, but man it would sure be cool...
Bang the head that doesn't bang!
I like to think of distributed net in the same context as the NASA Deep Space 1 mission that just flew by comet Braille.
-DN (distributed.net) has had it's share of glitches and trouble, but now it represents a technology that we can apply to other problems.
-DS1 has had a few glitches of its own. The ION engine wouldn't start properly, and then it mysteriously started working after a while. Of course, we figured out what was wrong, and that seems to be a normal characteristic of brand new ION engines. Overall, the DS1 ION engine has operated for 1800 hours, vindicating the original concept.
-DN tackles a current political issue, but the problem is technically boring. Cryptology is hot in the news today, but we all know the outcome of the DN problem. We'll find the key. But along the way we will learn a great deal about how to build vastly distributed programs running with donated computer time.
-DS1 also tackeled a current political issue, but it was essentially boring. DS1 flew by astroid Braille. Asteroids are in the news, but DS1 was so far away from it that the asteroid occupied only 4 pixels in the CCD. It also appears that there was a problem with the tracking system, so there might not be any better photos. Boring! But we're learning a tremendous amount about how to build spacecraft that can automatically perform their own navigation.
SETI at Home's biggest mistake is that they re-invented the wheel and made all the mistakes they would have avoided if they'd had some help. They have the right problem. We're all interested in finding alien life. But they could learned something from the distributed net people.
If tits were wings it'd be flying around.
Come on guys, now that we know Seti@home is just a bunch of no-good, no-good-dooers, lets all stop wasting CPU time on aliens that we aren't going to find (come on, they are out there, but too far) and break some encryption! That is something we can use right now!
Don't get mad about what I called seti@home. I run both (on diff computers) although I am thinking of changing to both RC5.
Corndog
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.
slashdot broke my sig
How about processing the human genome information?
The data itself is going to be simple and compressible (there are only 4 "letters" in DNA), so it can be sent out in significant size packets, but the actual information (open reading frames, splice sites, etc.) are rather difficult to pick out, being dependent on context, statistical probability, and other fuzzy things.
Just seems like a more thorough job could be done by distributing the analysis, instead of limiting what's considered likely in order to cut down on the burden on the available computers, as i had read that they were doing.
Perhaps, instead of trying to distribute the cracking of some cypher, or finding ET, people need to sign up for "distributed computing." What I mean is, people sign up to use some client software to do any project someone needs more than one or two computers to solve, even if they only need one CPU-year, if they provide the client-side software to do the number-crunching, it gets downloaded and executed.
Of course, the software would need to be small, and there would probably have to be some semi-centralized agent for everyone to get it from, and there would have to be a "validation" process to make sure someone wasn't just trying to find all the combinations of the letters in the alphabet that make cool names for their EverQuest character.
Thil promises to get big. I mean, they had a measurable backlog on their calculations at SETI, but it's dwindling quickly. This shouldn't make us upset, we should be glad that we have proven this can work. Not only that, but we've proven there are more people than they expected would be willing to participate.
What if they figured out a way to distribute the calcs on Pi or the solution to the human genome? We could probably find a cure for cancer in a month if they could figure out how to distribute the work. If it can be calculated, we could probably cut the calculation time down to virtually nothing. Not only that, but we've proven we can by laying the smack down on this whole ET-search.
So, what we need is an agency (/.@home?) to organize and distribute the plethora of projects out there that have one year project times or greater. Of course, one of the distributed projects could be the assignment and distribution of the projects. Maybe give that job to people who have proven dedicated to "the cause," a time-served promotion schedule, of sorts, like in a business.
Or something.
-Ristoril
One of the major problems they've had from the begining is that Aricebo doesn't have any sort of reliably fast connection. They actually snail mail the data on DAT tape from the observatory to Berkeley.
The 3DNow! advocacy guy's got it all wrong. It is a conspiracy from the NSA, FBI and CIA to make people stop donating their spare CPU time to Distributed.net.
- Da Lawn
't used to be LawnMOWER, really...
(there are only 4 "letters" in DNA)
<Counts./>
<Counts again./>
Wait a second!
<Counts one more time./>it sure seems to me that there are only three letters in DNA!
</JOKE>
Why is this article called "The Truth About SETI@HOME"? It's not more the truth than any of the usual Slashdot postings.
(Same for this flood of articles from osOpinion. Anybody, knowledgeable or not, can get his stuff published there, and all of Slashdot, LinuxToday and LWN will start a big fuss about it. It's just a waste of time.)
solving the "hacked client" problem when giving away client source would be easy: the server would need to keep track on who processed what data and send out some packets (maybe 5% or 2%) to different people and compare the results. i am sure the extra performance of tuned clients will outwight the checking overhead. once someone is found cheatings they are out.. comparing would work for the seti test. with the RC5 contest or finding primes it would not be that easy: the result of the 2% double packets would be in most cases "not a hit" and it would be unlikely to find someone who cheats that way. one way to solve that problem would be to demand that clients send a hash value of some intermediate results back that make shure the client has completed most of the processing steps.. and that values can be double checked..
mond.
A quote taken from the Seti@home page;9
http://setiathome.ssl.berkeley.edu/faq.html#q1.
"We decided not to make source code available for security reasons and for science reasons as well. We have to have everyone do the exact same analysis, or we can't have any control over our research and be confident in our results.We were also worried that there may be a few people that want to deliberately try to screw up our database and server."
As I read this above, the reason they are not distributing source, is to keep the data taint to the minimum. For a scientific analasys you would want as few unknown variables as possible. Keeping a contiguous software base from start to end on the project, ( at least the core computation part ) assures that the data is processed via the exact same instructions. By allowing anyone to construct a more efficient client, you're adding(potentially) small changes into the math. The amount of calculations over that minor 320~k block of data is staggering. Similar to the "Butterfly" example in chaos theory, a minor warble in a single math calculation may have no noticeable effect a dozen times.. but a million?
Yes, I may be blowing this out of proportion. Yes, I know that there does not need to be a contiguous analasys scheme from start to end in the case of seti@home, Yes, I feel that they should consider (as in the 3dnow article) NDA's for faster clients. But I feel that the above quoted statement says things clear enough to me.
Yes. They should not trust a valuable data block to a single computer. I'm assuming that there is a very robust system of checks and balances installed to check and re-check, and re-check every number crunched by passing the same block to multiple machines.
As for the second half of that statement, it's to prevent people who -don't- care about the project to get their jollies in raising their stats. Look at all the todger waving that goes along with the rankings... "_MY_ team is #1..." Yes it is still possible to fake packets, as has been evidinced, but with open source clients, it's trivial.
Yes. I believe in Open Source. However I know there is a time and place for it, scientific analasys, to me, is not one of them. RC5? Sure.. crack keys by brute force.. no analasys needed there. But SETI@home? This is science... This is for a more worthy cause than bragging to your mates about how your machine crunched more than theirs and you're cooler than them...
Seti@home definitely needs to ramp up their block construction process if what is in the 3dnow article is true. File "Running out of blocks to process" under 'Problems we -want- to have' How many scientists would -kill- to have too much processing power available?
Hell.. make a "variable" scientific analysis engine for distributed computing, give the science labs of the planet access to all the crunching they could ever dream of..
As always, my own opinion.
I don't like this guys attitude at all. He's angry because SETI@home has limited resources? They spend a fortune to use that radio telescope and distribute the work units, but thats not good enough for dude, he wants more. He is angry because he's "sacrificing" his idle cpu cycles. Its almost as if he feels its his RIGHT to help out when in fact its a privilege. They have every right to make the client as slow as they want. They have absolutely no obligation to open source it or improve the speed. Its their toy, and they are only letting us play with it.
I'm happy for SETI@home. I think its great that they've got 8 million volunteers and have managed to (almost) process all the data they've acquired. I hope they aren't completely overwhelmed, though. It must cost to server up all those work units. Something like 40 gigs a day, I think it is. Thankfully they have all them corporate sponsors.
I think it would be interesting if they open sourced it, but I understand why they haven't.
The author claim that if he have faster code, he will shutdown his computer at night.
...
I don't think it's gonna happen. People will still make their seti@home software run at night. Having fatser code will only enable them to do even more workunits.
Also the number of people who have 3dnow pr P3 is a lot smaller than the number of people who have P2, Pentium, PowerPC, Alpha, Sparc,
Optimizing for 3dnow will only enable a small amount of people to get faster performance.
I'm in favor of opening the source code for seti@home, they should not fear having code out there that produce false result because they could easily recompute the workunit with their version to see if it's true. And if too many bad result came from one person, they could easily cancel his account.
Opening the source will enable other people to correct bugs (the windows version is really not stable enough to run 24hrs/day) and optimize the code (again the window version is more than 2 times slower than the linux version - ok the gfx take more time to compute, but it should not be more than 2 timer slower - I've tested the 2 versions on my laptop).
Opening the source will also enable other scientist (with computer programming knowledge) to check the source to make sure that the computation are done right.
It's kind of contreversial for scientist to release closed thing. Science it about peer-review, all their work whould be peer-reviewable including the source code of their programs.
Note that they should not only open the source of the client but of all the other part of the system. This would enable other people to adapt the application to work with other projects and to enable amateur radio-astronomer to analise theire own observation with well-know algorithm and maybe to set-up their own distributed system to analyse the data they collect.
Okay, I don't want to hear any more about SETI@Home not releasing the source code. Here is the real deal on all of this. Do any of you wonder why SGI is blowing the doors off of everybody else? Do you wonder why they crank blocks in under 3 hours? It's not because they have superior hardware, it's because they have the all-powerful SETI@Home client source code. They've gone in and tweaked it so that the FFT (fast fourier transforms) routines use the optimized math libraries (they didn't previously). Bam, instant boost for SGI. Sun has done the same thing, you just can't notice since their average block rate hasn't dropped down yet (they've only been using the optimized client for about 2 weeks now). Both the SGI and the Sun clients had to pass certain SETI@Home tests to be allowed by SETI@Home (they had to crank a block and return results within a certain amount of precision and accuracy).
Both Sun and SGI have offered the optimized clients to SETI@Home to distribute on their home page, but SETI@Home doesn't want them (they don't want forks in the code base or something like that).
That's funny. They are, indeed, blatantly wasting their computer power. It is unreasonable that anyone would send out CD data to encode, but the idea that in a single day, we could've encoded a great portion, if not all, of the CD's ever produced.
Someone made a good comment when they said that the main problem with SETI@home is their unwillingness to call on the community, just like the legendary PHB's of every major corporation. They manage out of fear, rather than by communicating with the people.
What should SETI@Home do about it? Limit the submission of units to one machine per email address. Disallow the transfer of units between accounts. Retire the Top 20 teams and accounts of all categories every 2 months, that will make it less appealing to push so hard to the top.
But, above all, let people have the fastest client software possible, that is the least they deserve if you want them to support the project. Put the code into open source and let the best coders of the planet tackle it!
Cynical translation: "Kick off all those darned RISC users with their really fast floating point units and their farms of multiprocessor servers! Let us recode your client so our favorite processor looks better!"
Now I remember why we're looking for intelligence Out There....
Stupid job ads, weird spam, occasional insight at
n optimizations != n different source trees
He was especially talking about optimizing the FFT routine using special instructions from the 3dnow instruction set. Since this function plays a big role in overall computing time, this would have speeded up the whole process noticeable.
You can maintain portability and `speed hacks' for special platforms in one tree. Look at PostgreSQL, GNU libc, strace, MySQL. They all contain assembler code for improving speed on certain setups while supporting various platforms.
35GB I believe is what SETI is saying per block.
I really hate to see all this political ire being directed towards such a novel and well meaning scientific endeavor, though I suppose that human nature mandates it. It would be poetic justice for such a project to be canceled because of people bickering about their 'score' not being fair or because the code isn't available as open source. Participate or don't, but don't ruin the fun and the novel experience for the rest of us.
I want to ditch the GUI client and start using the CLI one, but I need a graceful transition. I mean, what does the system do if it sends out a block and it never gets the work back? I guess I could leave a little hole in the sky! Thanks,
Blar.
...the fact that when they first started having problems, they blamed it on the linux community, saying that we modified the clients to report more packets completed than actually were for the purpose of getting higher rankings. As a community, we did not do this. Perhaps a few linux users did, but they blamrd the Linuc community as a WHOLE. Till I can get an apology to the Linuc Community from them, no SETI@Home packets will ever pass through my computer.
-- Wiccan Army, 13th Airborne Division "We will not fly silently into the night"
so a distributed computing experiment succeeds past its own expectations, and an article manages to put a negative spin on it because some AMD fans don't get to optimize the code for 3dnow while there's talk of Intel doing it for MMX or its successor. colour me unimpressed about the complaint, and congrats to the Seti@Home people for managing to get their work done!
if it is not a competition to you then why do you care? If you were really interested in the success of the project you would welcome all of the "big iron" with open arms so that it was a success. It just so happens that quite a few people that "are actually interested in the SETI project" have access to some rather powerful equipment at work. If you had the same access to equipment would you turn your back on it and just use your cyrix 200? I didn't think so.
Oh, and yes I do fall into that group of people that have access to some very powerful equipment and I'm using it to run the seti@home client, and due to that my group is "way up there" shall we say. It does not mean that I am not actually interested in the project. I think that if you checked you would find that even the large companies that you see as groups are actually run by just a bunch of engineers that are interested in the project and started running the client on what they have available to them (at least that is the way it is here)
With your first line you are making yourself sound like a hipocrite.
I think its pretty sad to see that people think that running out of work to do for Seti@Home is a bad thing. They only get 35gb of data/day (~100000 WU/day) If they can't keep up, then Wow! Pat ourselves on the back and congratulate ourselves on a model that works well. Then think of something else useful to apply that model too. Universities the world over are shelling out tens of thousands of dollars to build measly 150 node Beowulf clusters so they can chunk through lengthy calculations. By the very nature of these clusters, the processing is done in parallel and is latency tolerant. Just think of what we can do to help the scientific community at large by distributing calculations over 150,000(!) nodes. I know that not everything would work well like this, but still...
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.
They're definitely short of data to be processed by an order of magnitude. It shows how everyone wants to find life on other planets but no-one wants to pay for more telescopes.
Of course I'm a hypocrite! I even know how to spell it. What where you thinking?
And, thanks for caring. I have no doubt that some very seriously interested people are using fast machines. It's also clear that some people with a lot of horsepower are in a big race to see who can do the most.
Insane speed doesn't really buy much in this case. The SETI project can only collect data during a limited time each year. At the current rate it will be used up a long time before the next session. In the meantime, the handful of people on the other end have to deal with all the stuff that comes back. The client is just doing the front-end work. Any interesting signals have to be handled individually. If all the homework gets done this week then most of the good stuff will just sit around waiting for someone to look at it.
On the other hand, if they were able to do some more programming to expand the search using the available data we might have a different story.
You never really know how close to the edge you can go until you fall off.
I still maintain that the SETI@Home folks need to be doing a much better job of letting people know about how much work is going wasted, and what they can do about it, if anything.
A long time ago, they indicated that if they had enough people, they might try to increase the depth of analysis performed, or to add more frequency bands to their Areceibo receiver rig so that they'd have more data. I really hope they do this.. they have obviously proven that they can get an enormous amount of computer time for it. (And not 700 years like the 3dnow! article said.. more like 38,000 years so far).
On the positive side, they are increasing the amount of graphs and data available to track the project, but without the context of how much of that work is being repeated, it means nothing at all.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
SETI@home is about donating your (spare) processor time to a (in my opinion) good cause.
If a big company with lots of processor power wants to donate some processor time, so be it. The point is to find ET! It is not to get to the top of the rankings.
If SETI@home runs out of data, well, they can either start recycling through the blocks that they havn't heard from (You know, the people who run it thinking it may be nice, and then give up seeing how long it takes), or just stop for a few weeks until they get the data to send out.
Insert wit here.
Phew, I'm not used to waddling around in asbestos underwear anymore .. anyway, I made an update to the disputed editorial at the former location that replies to some of the comments made here and in other forums, check it out if you really care.
Armin Lenz
I like the distributed movie rendering... but the distributed spider concept...wow.
That's something that could be *used* by anyone, every day. The big problem, of course, is the load on the on the host end. Unless someone had a boatload of cash to spork over, it would almost have to be done by someone established...
(Anyone at AltaVista listening??)
I'd sign up for this one.
A lot of the seti@home promotion I see seems focused on the competition and who can do more processing. It would be interesting to have a site that could coordinate multiple projects and possibly provide a framework for different projects. Then, various parties could put up tasks that they want to see done. The user could then choose what they wanted to work on. Group competition could be handled by the central clearing house site.
If seti was ran dry, your client could do primes or something else. Groups could compete on total processing or on projects. Contests? Different Projects could employ rewards or pretty graphics to entice people to help out.
The software could be an client that runs modules defining the work to be done and display, if any.
It would be important to allow people to pick the projects they want to work on, as some may have reasons for or against certain projects. But the client or site could indicate or suggest when a certain project has surplus computer time. It would also allow for that time to be automatically redirected to alternative projects when no work is available for your favorite, or if you just want some variety in the display (if used as a screen saver).
distributed.net seems to be doing some of this, in that it looks like they have different projects, but the projects of very math/cryto focused.
As for open source, it would seem to me that with zero processing cost, you would naturally double check your results irregardless of the availability of the source code. Honesty may be one reason, but I'm sure we could generate a list of ways packets could be corrupted, or computers returning erratic results. You kind of have to look at this as one big, powerful, error-prone computer.
If you want, you can join in with one or both of the groups I know that are trying to do just this sort of thing. I posted the URLs in the reply just prior to this, and don't want to start getting redundant, here.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I think that the seti@home folks have to choose
some linux guru, anyone well know. And ask him
to make an optimized version of the program.
I seems that the code works with large amount
of memory and makes the cache incoherent. So you
get more speed with more bus speed.
My two cents.
OverLord
Both of these problems can be dealt with if you have massive redundancy. SETI now has about 900,000 participants, about three times as many as projected initially. There's plenty of room for redundancy there.
SETI works like this: you get a block of data, and then your client is supposed to apply several transformations followed by Fast Fourier Transforms. If any of these Fourier results look significant, the client is supposed to tell the server.
To turn this into an open protocol, we simply should require clients to compute an MD5 signature of each of their Fourier transformed data, then compute a single signature of all those signatures, and send that back to the server, in addition to the regular notification of significant results.
The server keeps a database of these signatures, and in fact sends every batch of data to at least three different machines, preferably running different versions of the client on different hardware at different times in different parts of the world. If the received results coincide, everything is ok; if not, the server does the calculation itself and blacklists the bogus clients. Bogus clients should still be fed bogus data, just to keep them busy.
A public access library of data packets and associated correct MD5 result signatures should be available so that people can check their hacked version of the client against it.
--
I'm quite sure some knucklehead out there will hack a client to deaht and mess with their heads a little. Its not as if not using an OSS solution is circumventing hacking of any sorts.
-
ping -f 255.255.255.255 # if only
SETI does not cover 100% of the earth surface/sky. I thought the origional moan was a lack of CPU power to get the job done. Now after the problem is solved we now run into a lack of data!?!? We have done our part in this endeavor, now its time for SETI to do their job and get more data.
In their technical news sections the following is listed: July 17, 1999 We are awaiting the arrival of a RAID controller card and database server software for our Sun 450 server. When these items arrive we'll do a major (and hopefully final) upgrade on our server architecture.
1. From their FAQ: How is data collected from the telescope and transmitted to other machines for analysis?
Data is recorded on high density tapes at the Arecibo telescope in Puerto Rico, about one 35 Gbyte tape per day, then mailed to Berkeley, then divided into 0.25 Mbyte chunks which get sent from the Seti@Home server over the internet to people around the world to analyze. Arecibo does not have a high bandwidth internet connection, so data must go by snail mail to Berkeley at first.
35 GB of data per day / .25 MB of data per unit = 140,000 units per day!! They cannot make data to process any faster than they can get from the telescope, so there is a physical limit. Their statistics page says nearly 300,000 units turned in within 24 hours. Unless they have a backlog of tapes from Arecibo, of course there will be duplication here.
2. From the FAQ: Is it likely that so many people sign up that you won't always have enough Arecibo data to feed all the clients? If so, how will this be handled?
It's possible. Up to a point, we will handle it by sending the same data to more than one user. Beyond that, if we can afford it, we will set up another data recorder at Arecibo and record a wider frequency range (our current system records only 2.5 MHz out of SERENDIP's 100 MHz bandwidth).
They'll get more data if they can afford it.
3. It's not fair to compare this to distributed.net: This is a scientific experiment. It's not a race. It's debatable, but I think they are justified if they don't want release their source code--they want to have it controlled. They need that to back up any results they get. Also, you have to remember there is no 'right' answer here. There is no secret key that unlocks a message we understand. We don't know if there is something special in all that data from the telescope. With d.net, you know there is an answer, and you know you should be able to understand it. The Seti@Home project hasn't been perfect, but these kinds of accusations are groundless. He talks about how they waste all this valuable CPU time, but isn't the point of these distributed projects to take advantage of CPU time that would otherwise do NOTHING? So before you go cursing Seti@Home, please consider what I've said here before you erase the client from your HD.
I guess I don't completely understand this situation, but let me try to pick my words correctly: the Fullon3d web site is labeling Seti@Home an enemy, they want optimized software, and they keep saying Seti@Home is trying to stall. Ok...I still don't get it.
1) I guess we could start by saying the Seti@Home Project is not a video game; it is a distributed computing project connecting hundreds of thousands of computers actively working on the same task. All of this optimization stuff doesn't mean a thing for this project and it's goals. Fullon3d is also reporting that the Seti@Home Project has a lot of competition, which is entirely true. And, as a way to curb this growing *obsession* with work units, they propose the following:
-----
"Limit the submission of units to one machine per email address.
Disallow the transfer of units between accounts.
Retire the Top 20 teams and accounts of all categories every 2 months, that will make it less appealing to push so hard to the top."
-----
Of course, they want to stigmatize competition, but yet, they want to optimize the client to make processing units faster!! Seems a bit contradicting doesn't it? Also, I'm fine running the client software on my P166 comp with 88mb of memory. IMHO, the project is running fine. What need will making the client run *a little* faster fill?
*
2) Everyone has already seen the negative aspects of opening the source, so I don't have to refresh your minds. But, let's think about this situation with some common sense; there is no need to label Seti the enemy.
*
3) Oh yeah one more thing: fullon3d was comparing the Seti@Home project to this:
-----
"How would you feel building a road to the hungry people of the world with your bare hands while the initiator of the project doesn't want you to have shovels because they didn't think to buy trucks and groceries yet?"
-----
What? They are two unrelated situations that deal with different varibles and have no relevance on either of them! The fact is, if you don't want to help Seti, don't download the program.
Rajiv Varma
scientists think differently than hackers. If something works and will get things done eventually, that's what they will stick with. Think of it from their point of view; the project lifetime is an estimated 2 years. If they are already getting enough WC turnaround to analyze all the telescope data gathered in 2 years with their current userbase, then who cares if the code is not optimized? They could care less that your stats look worse than Team SGI or whoever. Not to mention the issues of security and scientific reproducibility. The point is they are getting their data analyzed, which is what they set out to do.
It seems to me that Armin didn't really bother to RTFM (or actually RTFfaq), it clearly explains why seti@home is not open sourced.
Well I guess my Windows 98 partition running the win*NT* ahahah (win32 poopie) CLI client isnt really working must be a figment of my imagination that I have 51 units done.
Geez. Success! How terrible!
If the SETI people would remove their heads from their arses, they'd see the gem they have. The have perhaps the largest computer system in the world, and rather than take advantage of it, they're trying to SLOW THINGS DOWN ??!?!?
This is a public crime!
Here's what they SHOULD do...
1) Announce to the world the overwhelming popularity and success of the program. Send out little pins to the top 500, that says "I'm a top 500 contributor to SETI!" Make sure there's a green alien in the corner. Such pins can be made for $0.10 apiece, and most people would be very proud to wear them. (I would be!)
Maybe even announce "eligibility" to the top 5,000 to buy (wink wink!) a poster proclaiming the contribution(s) you've made. Take the proceeds and use it to buy more equipment. Post on a website where those funds are going, and demonstrate their usefullness in the program.
2) Put a web-site up, outlining the Unit deprivation problem, and what needs to happen to crank out even more units. Give lots of press to contributors, and make sure there are lots of chat lines available for people to talk, vent, and argue about whether or not the pyramids on mars are, in fact, human.
Give a nice, plaque to contributors over $300 or so. (can be had for under $20 in bulk)
3) Instead of sending out recycled units covertly, send out the recycled units, and proclaim that they are "re-examining" these units, to ensure the validity of the original calculations. Make sure that such units are, in fact, compared to the originals. Make sure the user KNOWS when his/her computer is "re-examining" a unit.
Any thoughts on this?
Such childishness.
Besides RC5 is boring!
A generic architecture for distributed computing projects.
SETI searching, RC5 cracking, CGI Movie rendering... Whatever.
Deleted
Their "hardware" is cheap (internet access, zillions of cheap computers), and their raw data is expensive (radio telescope time, real-time data). What's so suprising about SETI fussing over the data and not the software/hardware? Efficient code saves hardware, and that's not their bottleneck.
This article is asinine, moderation is all well and good, but what can we do when editors post truly idiotic stories?
Having tested on many machines, it is clear that there are optimization issues, especially with graphics. You pay a lot for those pretty graphs.
Here are some of the average times I've gotten:
(WU = Work Unit)
Windows NT 4, Pentium II 350 Mhz: ~25 hours/WU
Windows NT 4, Pentium II 350 Mhz, no graphics: ~12 hours/WU
Linux, Pentium 75 Mhz: 65 hours/WU
Windows NT 4, Pentium 150 Mhz (laptop): ~150 hours/WU
Windows NT 4, Pentium 150 Mhz (laptop), no graphics: ~50 hours/WU.
(All NT boxes had "run in background" set.)
With these numbers, it is clear that the graph greatly effect performance. I suspect that the relatively superior performance on the Linux box is because NT degrades the priority of any non-foreground process.
I do wish that Seti would make this more clear at their site. It isn't immediately obvious, and I probably wouldn't have noticed myself if I hadn't wondered why my Linux box (no graphic version) seemed to do so much better than the NT PII boxes.
Still, what a lot of people miss is that this is an experiment. We shouldn't expect perfection immediately.
As for the source, well, I agree with Seti on this. The danger of muddying the results is far too great. In essence, we are donating CPU time. In doing so, it is basically theirs to do as they see fit. It is not us running a program for ourselves. It is them running a program using us as helpers. If you don't like that, don't participate.
The cake is a pie
It's inefficient to use more processing power than you have to.
Personally, I hold efficient use of resources to be a higher value than whatever's prompting people to defend the status quo here. It's one of the best features of hacker culture.
I had a friend once who said, "Why should I conserve paper? The trees are already cut down."
"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?"
It saves resources, free's up time for the other distributed causes or allows the computers to go to standby and save some energy. Just wasting time doing redundant work on poorly optimized code is not something worth defending, wasting resources is not a good thing wichever way you look at it.
God damn, these people are doing the best they can with the money they have, there is no point in making faster clients. Nobody cares about their wasted 'cpu cycles'. You leave the program on when you want, if doing twice as many work units isnt accomplishing anything then there is no point. Find something else to write code for in your spare time.
damn anal retentive geeks.
-I go to Rice, so figure out my email address
a.k.a. d-net v3.
I think it's at cosm.mithral.net
I didn't think of that possibility. However, if you use sufficient redundancy, then not all of the people processing that block will be running a hacked client. As long as there is one legitimate client which records a positive result back at d.net, then you can demonstrate that anybody else who said that block was a negative is running a broken (hacked) client. It would be necessary to send the redundant blocks to different clients simultaneously in order to make sure that any hacked clients are discovered before the user of the hacked client has an opportunity to cash in on their ill-gotten gains.
You could also seed the work units with positives and check to see which clients record those as negative results, and then ban those clients before they cause you to miss a real positive result. Seeding the work units like this means you have to be able to generate more than one positive result, which would be doable in SETI because a number of different results could be the pattern we're looking for. In other words, there are many possible positive results. Seeded positives might be impossible to use in key cracking because there should only be one key to the puzzle and if we already knew the key, we wouldn't need a contest to find it. The only solution that I can see for d.net would be for the client to not return a positive/negative result but just return the processed block for final interpretation as positive or negative back at the d.net server. Unfortunately this moves back into the "security through obscurity" model.
Your right to not believe: Americans United for Separation of Church and
Always thought it was a cool idea to have evolvable programs roam the net... but the project seems to have died :(
If they have no blocks let the clients sleep(). Then we could run both seti@home and d.net and whem seti@home sleep()s, rc5des get all the cpu power.
Well, that's a good point and it would carry more weight (for me) if you ran out of valid work units and your machine powered down. But it looks like seti may be just sending old wu's again to keep people running it, which I agree is a waste.
So, I don't disagree that efficiency is a good thing and that un-optimized clients is a bad thing. I didn't mean to (and I don't think I did) imply otherwise.
I guess I'm just thick because I still don't see how that article hopes to accomplish that. If a 3dnow optimized client appears tomorrow, everyone would still leave their machines on the same amount of time, no? If seti ran out of work units they would likely send out January again. What did I miss?
Since one of the biggest optimization problems seems to be in the graphics, and since only Windows (and Mac) boxes have graphics versions, I'd think a Linux advocate would be tickled about this. It certainly makes that OS look better than Windows. (I suspect it is also one reason why Team Slashdot is currently number one.)
The cake is a pie
I received a mudslide of emails and read several forum submissions here on Full On 3D, over at 3DNow.Org, Anandtech and Slashdot (which, ironically, chose to post this ragtag editorial but turned down the opportunity to get the word about 3DNow.Org, the 3DNow! coding workshop or Linux3D.Net out - go figure how much that makes them a gossippy place over one that cares for Linux and coders).
Ouch
They already compile on different compilers to support the different operating systems. Why can't they pass different optimization flags for the same source code? Right now this client uses only 486 code optimized by an obsolete egcs. With the latest egcs and Pentium II optimization I could get at least 33% faster.
Ok... I *JUST* got out my ammeter, and my computer takes in .5A. At least in America, we have 120 Volts, so thats 60 watts (if i am thinking correctly here, P=VI, right?) Now, in most parts of the country, energy is about 8-10 cents a kilowatt hour. According to my calculuations (correct me if im wrong here), but thats like 6 cents a night? I'd also like to point out that if a computer puts out any NOTICABLE heat of noise, you probably need a new computer, perferably not an intel *hint*
Years ago, before they had clients, before they had funding, they did have a web site to hype the idea. As a (very good) technologist with time & money on my hands, I wrote them on many ocassions. Did they respond to email? No. First sign of hype and hucksterism.
Flash forward to the project launch. The win95 client looks like a toy for eight graders. The web-site describes the science as if it were an article for Popular Mechanics. Is 'Scientific American' really so much over everyone's heads? Even a Phys Rev Letters style writeup might have been nice for the truly interested.
The first unix client picks a nice of 1 not a nice of 19. Hello? Are these college freshmen writing this code? Client won't work through socks or proxy. Now, sock & proxy are *not* difficult technologies. What a disappointment. Then there was the 'same work unit' fiasco.
Then, there's the security-through-obscurity issue. They can't release the source code because they have no security mechanism designed into the system. They're afraid of getting hacked. They need to design and implement a security system so that work unit results can't be forged, and then open-source the code.
Finally, there's the issue of the unexpected popularity of the project. Haven't they been looking at distributed.net, and seen what was going on there? Maybe learned a few technology if not PR lessons? And finally when they went home at night, didn't they think about who watches the TV shows like X-Files, Star Trek, etc. without thinking even once 'hey, our site might get real popular, real quick'?
This is the wrong way to do large-scale science, and I am disheartened by the inability of the scientific community, supposedly populated with bright, intelligent people, to act in a responsible and professional manner.
I am beta-testing the Intel hacked client. Here are some interesting tidbits:
1) My PPro 200 can process a unit with the hacked client in about 7.5 hours (compared to ~23 hrs before).
2) The hacked client is way too unstable for release and it crashes on my NT systems all the time.
I think the SETI@home people are doing a great job. I run web sites and it is hard enough to run one that gets a few hundred hits per day, much less million+ hits/day that the seti site must be getting.
The complainers seem to forget the fact that running a scientific experiment requires great control over the parameters. A bunch of barely tested hacked clients are the last thing these guys want.
Each different CPU may yeild slightly different results due to roundng, precision, and different Run Time Libraries. Especially with a FFT, these differences can accumulate faster than you think. So, if people run even more versions on more chips, 3d-now, SIMD, and so on, the number of variants explodes. Accuracy (& consistancy) is more important than speed in some cases.
That said, I'll kick some ASS if they are deliberatly sandbagging their code.
rbb (Yes, I've written FFT code in commercial software.)
The GPL is based on a philosophy. It's not a philosophy that everyone appreciates and like all philosophies, it has it's proponents and it's opponents. If you happen to like the BSD licenses better, feel free to use them for your program. It's up to the author of the program to choose which license suits their particular code-philosophy and really, it's nobody else's business. Just as your religion is not my business, and mine isn't your concern. One is not better than the other.
Also,
I agree that some good comments get moderated down just because they are anti-GPL but that is the fault of a few moderators, not all of them (us, I should say sometimes). All moderators have the power to remoderate comments that they feel have been unfairly downgraded and to tell Rob and Co. about any perceived misuse. Labeling all moderators is stupid since it's not one group, the roster rotates between all people with accounts who haven't checked the box saying they don't want to moderate. If you see moderators seemingly misusing their power to further their beliefs and not helping the discussion, please, for Pete's sake, email Rob and tell him about it. Don't just sit and complain.
Unlike prior distributed computing projects, the sole purpose of DIESP is to give nerds with flashy computers bragging rights over their friends. The compute task is still to be chosen, but will be something that exercises a good mix of integer and floating-point ops, and is highly optimizable to take advantage of the most arcane instruction-set extensions. The actual task will be meaningless, but who cares? (Our beta progam searches for Bible Code-type messages in the works of Nostradamus, and ray-traces the results.) It will be open source so that everyone can tweak it to their heart's content. We'll put up all kinds of statistics on the DIESP web site, and we're actively exploring logo partnerships with various hardware vendors and co-branded clients for major ISP's.
Another major innovation of DIESP is our unique Virtual Result Computation which eliminates the annoyances of other projects, like requiring you to leave your computer on all the time. Submit just one work unit, and, for a small fee, our VRC program will pretend that you're running at that speed on a virtual CPU(TM)(Patent Pending) and your statistics will be continuously updated! You may purchase as many virtual CPU's as you wish. We'll also be introducing our Premium program, where, for an extra fee, we'll assume that you're optimizing your client software and/or upgrading your hardware over time, so your virtual compute rate will gradually be increased.
I think that people forget that this Berkeley project is an experiment. The way I understand it, they are trying to establish whether this is even the right way to approach the problem. Sure its cool that they have almost a million computers working together on the same project... and no doubt the code could be faster... But it is not our place to tell them how to run their project. We volunteer to do the Seti processing. Its a donation. What they do with the time is up to them. Its bad Karma to give someone money then try to control how they spend it. Further, the Astronomy is the issue... not the computing efficiency. If the computers are blazing through the data faster than they can collect the data then I would not be surprised if they are considering increasing the amount of analyzing that the computers are doing... Working at a higher resolution or increasing the overall spectrum that we analyze. Quit being a bunch of computer geeks and go get some sun (I am a computer professional, BTW)! Sheesh.
Exactly. After all, they say up front that this is a "two year project". I'm sure that after two years, they'll have lots of ideas on things to improve. But thinking like scientists, they don't want to change things midstream.
(BTW: was that 23 hours for the graphics version?)
The cake is a pie
My semi-random thought:
Some MS people get it in their heads that MS should have a good showing in the S@H results. So they get approval from the company to set up a small server farm (so that they don't get a visit and an escort out of the building from corporate security, as is the custom for independent thinkers at MS).
They get a hold of a bunch of systems left over from the last major group upgrade. They are all the same speed & memory, all running NT with the same security hol...patch level. They started them all at the same time. So is it any surprise that they process blocks roughly in sync? Compound this with multiple clients per system, and periodic usage of the systems for other tasks, and you would have a wave-like effect as you've noticed. They turn in X000 blocks in a big hurry, then aren't heard from for a while.
That's my story, and I'm stickin' to it.
I think not...(*poof*)
Or maybe, it's multiple machines registered under one email address? Nah, much better to just speculate about the evilness of others...
I would like Seti@Home released under a open source liscense so I could run it on my own (home made) radio telescope. It seems it would be more efficient on my supercomputer the way it is now than running ham radio software in DosEMU and checking the screen everey know and then for a signal....
I don't understand why we cuold possibly be doing the same blocks over and over on purpose. Why can't they just grab more data. Point radio telescope outwards. Record. Process to the SETI block format. Distribute.
I just don't get it.
"...and Slashdot (which, ironically, chose to post this ragtag editorial but turned down the opportunity to get the word about 3DNow.Org, the 3DNow! coding workshop or Linux3D.Net out - go figure how much that makes them a gossippy place over one that cares for Linux and coders)."
Did this guy ever think that we (slashdotters) care about computing, not just alternative computing? Hey I resent being called gossippy! Did you all here what this guy said about us, he called us gossippy. We need to tell everyone quickly to no pay attention to his mindless garble
You so see the sarcasm there right?
..they/we/whomever found out that Seti@Home really
*is*
running a rendering farm, cleverly disguised as a distributed-alien-detecting-bit'o'software..
CN
So gcc, the gimp, gnome, and emacs are all useless for real work? Aside from the fact that there's gnu.misc.discuss for this, what is your definition of real work?
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Well there is one point that the author is not correct. Yeah it would be pretty cool for SETI@Home to be more open for the community. But if anyone remembers the last pitfalls in distributed.net and specially that hacker breaking all records in RC5 then there could be some ground for not being so open.
However I don't like how SETI@Home presently goes. Apart of being quite critical on the usefulness of such venture, I also tried to overcome my acidity and give a hand to these guys. However...
Yes the client is a terrible dumbiness. Sometimes I get the terrible feeling that I inserted some piece of Visual Basic in my hardware (Nooooo God! Nooooo! Oh it was just a nightmare...) No matter that you can control its niceties and some other stuff the thing is clearly raw. And it is quite weird that they hold such way for so long. Well let's face the facts. This thing may not happen in our lifetimes. But it is stupid to keep it running 5km/h when we can get it a little bit faster. Specially if we consider the amount of info we need to analyse.
I wonder why SETI@Home does not take an attitude neighboring BSD licensing styles. Something like this: you get some specifications, bla-bla-bla and send us any code you think useful on it. However We determine what goes and does not. It would really improve things a lot. Anyway even if the keep this enclosement this will not avoid them to face serious cracks in the future.
Meanwhile the author revolves some ideas about the possible "disconfort" SETI@Home has for having so many people on it. Well that could be quite true. In fact SETI on the whole has shown such behaviour in several places. It has grown from an elitist view of the project when it started. Some protocols of meeting "alien civilizations" transpire a behaviour that was quite typical on the 60's. Champagne, elite, jet-sets and a few dodos with enough money in their pockets to pay the first seats. Funny to see their faces in front of some mastodon half-brained being with tentacles in his face and only capable of saying the words: "tasty!". Just a joke sent by our friends from the other side of the Galaxy.
Why not? Clinton said we would go to Mars to "get them before us" in a "jokingly" reference to Independence Day film. If really there was someone in Mars (speculate about it) that would be a very disgusting joke... Martians could feel themselves offended enough to take some retribution.
One of the porters at SGI is tweaking it so that it'll run SGIs tuned MIPS FFT code. When finished it should be easier to port it to other PD optimized FFT codes or to other vendor's FFT code, so you should start seeing faster clients in the not too distant future.
One reason to not distribute multiple different tweaked clients is to keep the project as managable as possible. The guy who is handling the Unix ports is already pretty flooded with seti@home work.
Nobody is saying the GPL is more popular. I didn't see anyone saying that n% of unixes were open source...
The reason GPL is better is because it keeps people from closing the source again. If I write open source software to benefit my fellow computer users, I don't want someone turning around and closing that source later.
You would say that the GPL handles this by restricting freedom. But, I'd say that the freedom to plagarize code isn't one that I particularly care if I withhold from somebody whose only use of it would be to deny any benefits of open source to future users.
ie: BSD helps microsoft. Evidence: Win95(etc) TCP/IP based on BSD code, almost a direct ripoff. This is known because the attacks that work on BSD derivatives also worked identically on MS products.
GPL hurts companies like Microsoft. Not only can they not (legally) take a complete application like Apache, steal all the good innovations, close the source, and stick an MS label on it, but they have to compete with a project that they can't kill by forking to death.
If you can give me an example of how the GPL hurts users, the people who will run potential code that I may write, by guaranteeing that it will stay open source, well... I'd like to hear it.
Well, it doesn't even matter if it's released with a license that allows any derivative work to be made for non-private (testing, etc) uses.
Ideally it would be open source to help people run future projects like this, etc.
But, the current task is only to waste as few cycles as possible while cranking out SETI blocks. To do this they don't need to allow derivative forked projects or anything. All they need to do is let people read the code (or even parts of it ala d.net's RC5) so that we can suggest improvements.
A GPL or BSDL-ish license would only be icing on the cake.
This article is a good example of the typical GPL tripe that comes out any time one of these self-proclaimed h4x0rs wants to work on a particular project but doesn't get to. They find a project, demand open-source, and when they don't get it, they demonize the entire project. They accuse them of being "Afraid of the truth." They're threatened by real coders. What garbage. They just don't want to release the source -- some claim they could do a better job of writing it.. they don't care, nor should they. This is SETIs project, it's their code; if they wanted your help, they'd ask for it. In the meantime, it's not like they're taking food out of our mouths. Those of us who use the program choose to use the program. I'd never hesitate to turn my computer off when I want to just because I owe SETI that time. If you want to volunteer your time for SETI, volunteer it in the ways they're asking you to. If that rubs you the wrong way, don't freakin volunteer! Go find your own project to work on. Seems a lot more reasonable than smearing the project and putting this rabid spin on it just because they didn't let you help in the way you wanted to.
Oh, and I love the offhand and offtopic stab at slashdot, too. Perhaps it's gossipy, but that's alright. That's the point behind it. It's a news site, not a church for your particular brand of activism. I guess if they put a bigger spin on their stories, hyped them more in tune with your own ideology, they'd then become a more "caring" resource for "linux and coders." Of course I, for one, would stop visiting it. Thankfully, they aren't so limited in scope.
Come to think of it, how do we know that SETI@Home deals with radiotelescope data at all? It could be anything. For all we know, SETI@Home contributors could unwittingly be nodes in a vast NSA cryptanalysis machine.
I know people who stopped going to classes - mesmerized by S@H and other Windows screensavers.
bah, windows users.
-ssen
Insane speed would by a lot here. I cannot believe that the FFTs and doppler shift we are doing now are the only useful analyses that can be run on the data. SETI should be more flexible. If they see that they have (orders of magnitude) more processing power available to them then anticipated, they could broaden the project to include those other analyses that are were considered too cpu-intensive (or too farfetched ?) to be included in the first place.
Why not release a second set of clients that go over the same data, but in different ways ?
There may have been slight doubts about wether people would be allowed to know about the Deschall
;)
results. The problem is that its VERY hard for the govt to really shut down or stop deschall, because the knowledge of how it works is widespread, and so is the equipment to see if it was crackable - and crack we did. It was just an organizational challenge. It had a tangible result with a political repercussion. That was the real daddy of all cracks because it was the first succesful very wide distributed crack (at least to my knowledge).
Seti seems like a HUGE shot in the dark. If you read the FAQ, the chances of finding another IET civ out there is vanishingly small based on the sample set and other factors. They admit it themselves. So:
1) we dont even know if there will be a result. And when there's no result, we cant chalk it up to
just a bad set of client software or a bent Arciebo dish. There just might not be anyone there - and we cant even be sure, because the data sample is from an extremely narrow bandwidth of a small section of the sky.
2) SHOULD we find something, how the hell are we going to be sure we're allowed to know? I mean, ya this is sounding all X files and all - but its really not easy for someone to go home and figure out if someone stepped in and fudged the "no" results. There are no competing seti's like there was for Deschall - other groups could verify the efforts of Deschall (some dropped out, but I think SGI had its own internall effort, for eg).
The govertnments (probably those of Nato in this case) probably has some reason for not letting any concrete evidence of ETI getting out. Either we wont hear about it at all, or it will be accompanied by so much hype and other fuzzy claims or denials or what not, we wont know whats true and whats not (like area51 and other encounters nowadays, tho I personally dont believe in the astronomically improbable likelyhood of aliens having a symilar physiology to us, never mind having to be based on carbon like we are).
Couple those two things together, throw in SETI screaming for help wehn they reach loads that are equivalent to a 1/10th of what CDROM.COM handles constantly, make big parades and press releases of how Top level Sun Engineers have to walk in and help them because this is SOOOO cutting edge (and not that its a bad design), and you end up with a project that has TOTALLY lost all my faith.
Rc5's stats are way better, the foster competition and actually finding EVERY machine in your house and your friends' house and his workplace and everywhere that you can (and many places you SHOULDNT) and throw them into your team's stats. We eagerly await client updates, which, for DES at least, showed HUGE improvements over, say, Deschall (I remember 600Kk/s on my P133 in DESchall - with the RC5 client I think its 3-4 times that now!)
Not to mention SETI repeated keys for weeks, and is now trying to keep the load down (they admitted themselves they had problem with load months ago).
Lame.
Not that rc5's result is that interesting to me right now, I am actually trying to help setup an independent research team with some cycles and clients to calculate protein/enzyme interactions in human cells - something thats apparently much overlooked in North America (I dont know much about the org.chemistry in this effort, Im the unix guy
THAT would be a far more interesting and useful project than just cracking more keys to convince some entrenched non-science-educated politicians something we've been pounding over their heads for years (really, the mersenne prime search is more interesting to me than rc5 - I might switch soon, unless rc5 actually does some work on the Golomb Rulers project).
If you want more info on the computational chemistry shit, email rutile at home dotte com (decode that yerself) and he will explain what they're trying to do.