Slashdot Mirror
SETI@home: Research on the Research
Officer Larry writes "A professor and a graduate student at the University of South Carolina just posted a study into SETI@home work unit completion times. They came up with some pretty interesting results. It stems off Team Lamb Chop's work, but these guys are interested in how much variation there is in completion times if the same work unit is analyzed over and over again on the same system. It looks like they have other studies in the hopper. Warning: there looks to be quite a bit of statistics in this study..."
Any time Linux beats any other OS in anything, there are big screaming headlines, WOOHOO! CHECK THIS OUT! Linux best for ____ or whatever. They get beaten, and there is no summary of the results in the story summary! Virtually every other story summary has the main point of the article listed, but when Linux loses, you try to gloss over that fact. Clearly, Linux got its butt kicked and there are 'many statistics.' Hah.
Sadly, /. cannot take credit for killing tlc.com, it's been down for a spell already. Come kill my box instead.
-Hagbard (/. - Obelisk) Don't have my login at work... doh.
They did not use RH Linux.
The discovery of extraterrestrial life will likely revolutionize life on earth, probably ending war here so we can work together to wage war on aliens. But the aliens will be so much more advanced that we won't even try. I know, governments wage war, not people.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The built the DES cracker for less than $300k. But to what end? SETI@Home has excess processing power now - they don't need faster clients. The Ego is the only driving factor to churn out faster SETI units.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Since SETI is most likely purely CPU intensive, there is very little the OS can do to make it faster or slower (apart from deliberately getting in the way, of course). On the other hand, the compiler makes a tremendous difference, and so do the compilation options. Since we do not know which compiler was involved, and which options it was given, the benchmark is fairly useless.
Finally! A year of moderation! Ready for 2019?
What a great slashdot parody article! I mean, the irony of complaining about the benchmarking of Windows NT in a configuration where is is still faster than a Linux distribution. Or is the author poking fun at the idea of a Linux person trashing NT because the performace scales up as you add memory?
-- I browse at +5 with stripped sigs
weee
...how long till we have a SETI@home@home client to do this research on a distributed level...?
Argh, slashdot eats angle brackets in subjects. The subject should have read "WinNT needs >128M ram"
I would have said "it is interesting that Windows NT cannot run a WU at full speed with less than 128M of RAM. Other operating systems make effective use of 128M of memory, but NT needs 256M."
The entire process while working is 13 or 14megs in total. The WU is just 340k, The performance has less to do with the processor speed, but is more dependent on processor cache size and the FSB speed. I have K6-2 400's and K6-2 550's that perform exactly the same because they all have tiny 64K caches. A K6-III 400 out-performs a k6-2 550, the K6-III has a 256K cache. I also have sun ultrasparc systems, one at 167mhz completes within a hour of the 300mhz system. And I have an old HP 735 running at 125mhz, on HP-UX, a huge, bloated operating system (unlike microsoft though, here the hugeness and bloat are the price for HP-UX's flexibility, stability and utility, LVM kicks motherfucking ass!) and it completes a work unit just a little slower than the K6-2's.
The current Slashdot moderation system is made by gay communists!
When will setiathome go open source? Perhaps some compiler optimizations would hep. Who knows what demented troll is compiling your favorite platform's client.
The current Slashdot moderation system is made by gay communists!
This wang suggests testing linux by running the winnt commandline code via wine! Sure adding a layer of windows APIs on top of linux, that will really improve performance.
Debian 2.2 supports udma100, he should have been runing stable, but in anycase he should state exactly what he installed, and should describe what he removed from cron. A fat desktop system will have tons of programs installed. What he is testing is the performance of setiathome, exim, locate, logrotate, suidmanager, syslogd and half a dozen other programs/scripts all at the same time.
The current Slashdot moderation system is made by gay communists!
Today's vices may be tomorrow's virtues.
my conspiracy is that the SETI crew is pulling the wool over our eyes, getting us to do Carnivore-esque processing en masse.
Sorry, really I am... I have a problem... it was just staring at me... so blankly... an empty page without any posts...
I wasn't tring to get first post... really it just kinda happened... I didn't think, I just acted.. I don't know what I was thinking.
Please forgive me... I am a sick man
Oh god.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
IIRC SETI is privately funded so don't gripe about your dollars going to waste.
Considering the work unit times were 7-8 hours approximately, a standard deviation of 30-80 seconds is not bad!! That shows minimal interference from uncontrolled factors (other programs inconsistantly using processor resources, temperature, etc.) I commend them for detailed explanation of the statistics.
:) affects computation time.
What they need to do now (as they said) is do more than 5 trials for each configuration so their results are more reliable, THEN trying to decrease their standard deviations by controlling temperature, and other variables.
Figuring out which factors affect computation time would be interesting. Especially how the environment around the computer (temp, pressure, relative humidity
Also one thing that seemed to be missing from this article was reference to Roelof Englebrecht's data, collected over some period of time and posted on his SetiSpy web site here:
http://pages.tca.net/roelof/setispy/
Roelof and TLC's Max, are both the keepers of the TLC benchmark database and Roelof checks each and every submission to ensure that the data isn't corrupted somehow due to an unstable overclock.
In addition, I currently run the text client in WINE on my Red Hat 6.2 as standard practice and have submitted data to the TLC page for it. It runs just fine and in fact runs the WU FASTER (whether using the -win95 switch or the -nt40 switch) than either native winblows version when run on the same system via dual boot.
-- Win2k: "It's not so much that it's only 65,000 bugs, it's just that they stopped at 65,535 to prevent an overflow."
When I read the Athlon scores vs the Pentium III scores, they aligned with other benchmarks I've seen which compared the two chips. What's more interesting is that the fastest Athlon was 2 times faster than the fastest Mac. One might be tempted to say mhz do matter until you look at the clock on the PA-Risc. At less than half the clock speed, it blows the fastest Athlon out of the water. Looks like HP knows how to build a cpu.
they used an i686 compiled version of the seti client on a thunderbird.
Don't amd chips just repsond to i586 optimized instructions, and i686 instruction pairings slow it down?
Actually, since SETI is so CPU-intensive, the fact that Macs ranked low only means Mac users are busier doing important things on their computers, while Windows users aren't doing anything important. We're just busy creating.
:-) Hey, grow up okay? "Mac users are losers!"
Ahh, I'm just kidding. Who cares.
To me, you seem like your life priorities are a bit mixed up. Who cares! It's just a computer - don't wet your pants. Use what you like, and don't talk about what you don't. At least have a valid point.
See you.
The next comment I write will be ready soon, but subscribers can beat the rush and see it early!
Well I didn't do any scientific invesigation, but I notice my G4 500MHz Mac completes Photoshop filters CONSIDERABLY faster than the 1GHz (well it might be like 900 something MHz, i dunno) Pentium down the hall. It sure does FEEL like twice as fast, and probably is. But this is getting off-topic so I'll stop......
The next comment I write will be ready soon, but subscribers can beat the rush and see it early!
Any alien smarter than us is going to find us before we find them
Isn't that more reason to start searching now? You're right -- aliens may have "found" us long ago. So now it's our turn to find them. Later is better than never, no?
any alien dumber than us (i suppose thats what we are looking for) may not even respond
Respond to what?! SETI is a search. It's not a response. Search first. If you find even a "dumb" alien, wasn't that worth the search? As an analogy, do we search for new species on this planet so they can respond to us? Of course not. They're dumber than us, but still worth knowing about.
I don't run SETI@home (gasp!), but does the difference between having 128MB of main memory vs 256MB matter that much? I mean, the machine should be otherwise idle and unless the machine starts swapping it isn't going to make much of a difference how much memory you have.
In fact, the statistics show that SETI isn't that memory hungry, the differences between the two memory configurations where almost noise; less than a standard deviation in some cases.
I'm getting 403's from the web site
An Education is the Font of All Liberty
Also, they didn't seem to consider possibilities like the fact that a default install of RH Linux may run updatedb daily, which if using a slow drive with a lot of files could easily describe the variation. Instead, their first guess is 'unstable packages.' Wazzup? Academics...they love bizarre conclusions in favor of putting in that extra effort to find the truth. They spent enough time setting up the survey...why didn't they finish the job? (Answer: they were working on a deadline...and didn't allocate time to research the variation)
Our web host decided to take the server down for what has turned out to be a couple of day upgrade. We have put up up our site on a mirror in the meantime. You can check out the main Team Lamb Chop page here: tlc.hagabard.com and you can check out our benchmarking pages here: tlc.hagabard.com/bench/index.htm
Thanks for your support!
-zAmboni
-zAmboni
Team Ars Technica Lamb Chop
-zAmboni
-zAmboni
Team Ars Technica Lamb Chop
Uhm, "relied on third party tools written in visual basic" now that's something you made up :-)
Still, who cares reading those company "success stories", no matter which company or product they are coming from. I can't even take these stories serious if it's a product I like/support.
--------
I am so tied of site@home, when I finally got a monster PC to get some killer stat, they changed the client so that it took even longer and my speed gain was minimal. :-)
Why not support something like folding@home that at least has a slight change of doing some good or bad, but atleast something.
But then again, I can't join since stanford seems to have blocked my entire ISP. heh
--------
However, I doubt the differences in that kind of data are enough to justify the Linux performance by itself.
It runs slower on NT and Linux than on 98. Duh. This more an analysis on timeslices (if even that). Hardware platforms should have varied more. PPC Mips. HP. Vax. Wang. Everything. This article was useless.
I thought top-end Mac processors were 2x the speed of top-end Intel and climbing?
If you could afford a top-end machine, of course.
All I know is Macs sure aren't taxing their CPU's at home playing games...
I am for the complete Trantorization of Earth.
> No, he's not right. In fact, he's almost as
> wrong as he could be.
Is he?
Saying 100 light years wouldn't make us detected is like a caveman saying, "Gee, we can't throw a rock more than 20 Oog-lengths, so no one will find us!" Meanwhile, a satellite with square-inch resolution orbits overhead and spots the campfire at nighttime with no problems whatsoever.
We probably are found, and the fact we don't see a galaxy filled with immensly powerful artificial signals indicates either we are being directly shielded, or the standard galactic communication is hidden, piggybacked on background radiation ala Contact, or my favorite theory, there's much better ways to communicate than radio waves, so the period of EMF useage by a civilization is very brief.
I am for the complete Trantorization of Earth.
Ehh, my PII 266 takes > 50 hours, while my PIII 450 takes about 15 hours. First has 95, second 98. Is there THAT much difference between the two?
I am for the complete Trantorization of Earth.
While we haven't done anything nearly as scientifically viable as this study, our conclusion has been that the difference in processing speed between a 1Ghz and 866Mhz Intel processors (each with 128M RAM) is very slight - almost imperceptible in some cases.
Systems with larger L2 caches, however, seemed to have distinct performance advantages. How (or if) you can apply that information to non-SETI applications I will leave to you.
-Coach-
Perhaps the world's greatest tragedy is that ignorance is not impotence.
SETI fully explained and some views on alien physiology-- over 50 extrasolar planets have been discovered as of 2001.
I can't believe they didn't test any Mac platforms. Mac users are some of the most enthusiastic fans of SETI! Team MacAddict is #3 in the Club Competition , only behind Ars Technica and Team Art Bell. If fact they're almost tied with Team Art Bell, with only 5,000 users to Art Bell's 13,000 users !!
Cant this be implemented in hardware? maybe full-custom or semi-custom CMOS ASIC's would be possible, but its very expensive ofcouse.
It's good to see such a strong response from the community and we thank everyone that has given us constructive feedback. However, we feel that many of you have completely missed the purpose of the article.
The purpose of the article is NOT to compare OSs, get fast SETI@home times, or even to optimize the systems at all. We thought this was clearly stated in the abstract and methodology sections. Either we screwed up and did not make this apparent or people did not read the article. The study of optimizing systems and making SETI@home faster is already handled very well by Team Lamb Chop (if the site ever decides to come up...).
What we DID want to accomplish is to study work unit completion time VARIATION . This question was prompted by our reading of the SETI literature which had not dealt with this matter. Our research question was: on a "typical" system, how much does the completion time vary from instance to instance? If I run the same work unit over and over, how much will my completion time vary? I don't know about the rest of you, but when I run SETI@home on my systems, I do not disable all other processes (including cron or anything else). If we did disable anything out of the ordinary, then we did not accomplish our goals. As was clearly stated in the methodology section, we used the default settings for each OS.
A separate question was the method used for us to arrive at this conclusion: testing several OSs in several configurations on the same platform. At this time, this method seems a useful one for comparing configurations.
Now that we have a baseline, we are going to continue and try to figure out the questions posed in the article. Such as: why does Linux have such a high variance in comparision to the other OSs? We have collected many great suggestions and I will test all of them and post the results.
In any case, this article cannot be used to compare OS to OS performance. Not only is that not the purpose of the article, but there are too many confounding variables--many of which have been raised here.