PLA RUNS SETI@HOME



SETI@home uses the spare CPU time from approximately 2.5 million donors to look for possible signs of extraterrestrial life in radio signals received by the dish at Arecibo, Puerto Rico. Currently, it qualifies as the single most powerful supercomputer on Earth (currently pushing 29 teraflops), for a cost far below a conventional supercomputer (under $1 million). For comparison, IBM's ASCI White rates as the second most powerful supercomputer, at 12 teraflops and a cost of $110 million. For another comparison, ENKI, my Beowulf cluster, performs at around 200 megaflops (1 teraflop = 1 million megaflops), and cost under $500.

I have run the SETI@home client on every computer I touch (for which I could get permission, of course) since a month and a half after the project began. In that time, I've processed a good number of work units, as you can see from my current stats.

If you have a computer, most likely it sits around for over 95% of the day either turned off, or using very little CPU (watching a DVD, surfing the web, using Word or Excel, or just about any other normal task, takes under 25% of the processing power available to a low-end PIII). So join the search! It works very simply, just go to the SETI@home homepage, download a client (for most people choose the Windoze version), and run the file you get. Even if you only have a dial-up connection, the SETI@home client only transmits 340k per work unit, and a PIII/800 will finish approximately four work units per day.

If you have a Unix/Linux machine (or network of them ) and want to join the search, but don't want the hassle of administering them, feel free to give me an account, and I will happily run it on your machines for you. Currently, I do this for one medium-sized company (very few of their machines), two ISPs, and my parents.

The table below shows all of the machines on which I can verify that I have SETI@home running (I may have a few more, but cannot telnet into them (ie, Windoze boxes) and do not have regular physical access to them). The columns seem pretty self explanatory, with a few notes. First, any locations listed as "Other" mean that the owner of that computer, although giving me permission to use it, would rather not have the public know that they run SETI@home on some of their machines. Next, a question-mark in the "1% time" column means that, for whatever reason (usually too high of a normal CPU load), I could not measure an accurate 1% time. Finally, an asterisk in the "1% time" column means that the corresponding computer has a problem which prevents it from operating at peak performance.

Name Where CPU Type OS Client Version 1% Time
pchost31_18 Other 2x PIII/800 Linux 2.2.14 (RH) 3.03.i686-pc-linux-gnu-gnulibc2.1 347s
wbdespres2 Other 1x PIII/733 Windows NT 4.0 3.03.i386-winnt-cmdline 336s
sabotage Efortress 2x PII/350 Linux 2.2.15 (SW) 3.03.i686-pc-linux-gnu-gnulibc2.1 345s
endless Efortress 1x PIII/600 Linux 2.2.14 (SW) 3.03.i686-pc-linux-gnu-gnulibc2.1 406s
teleute Home 1x PIII/560 Windows 2000 3.03.i386-winnt-cmdline 346s
users TMOK 2x PII/266 FreeBSD/i386 3.2 3.03.i386-unknown-freebsd2.2.8 1004s
aspect Parents 1x PII/412 Windows 98 2.4.i386-winnt-cmdline ?
lucien Home 1x PII/300 Linux 2.2.16 (SW) 3.03.i686-pc-linux-gnu-gnulibc2.1 783s
morgana URI 1x PII/300 Linux 2.2.14 (RH) 3.03.i686-pc-linux-gnu-gnulibc2.1 676s
pchost31_26 Other 1x PII/266 Linux 2.2.5 (RH) 3.03.i686-pc-linux-gnu-gnulibc2.1 671s
mercy Efortress 1x P5/233mmx Linux 2.2.13 (SW) 3.03.i386-pc-linux-gnu-gnulibc2.1 ? 1355s
triscuit Parents 1x P5/200mmx Linux 2.2.6 (SW) 3.03.i386-pc-linux-gnulibc1-static 1489s
damiana Home 1x P5/200mmx Linux 2.2.16 (SW) 3.03.i386-pc-linux-gnu-gnulibc2.1 1502s
wbdespres Other 1x P5/233 Windows NT 4.0 3.03.i386-winnt-cmdline 1555s
pchost31_52 Other 1x P5/200 Linux 2.2.14 (RH) 3.03.i386-pc-linux-gnu-gnulibc2.1 1785s
eris Parents 1x P5/200mob Linux 2.2.6 (SW) 3.0.i386-pc-linux-gnulibc1-static 845s
bimbo Home 1x P5/166 Linux 2.2.16 (SW) 3.03.i386-pc-linux-gnu-gnulibc2.1 * 2328s

I have also written a simple script to buffer workunits, for (unix) machines with irregular access to the internet (or just to allow processing to continue during the SETI@home server's frequent downtimes). Unlike the dozens of other workunit buffering programs out there, this one does absolutely nothing fancy. You tell it the directories to use, and it runs them, trying to keep as many ready with a fresh workunit as posible. Feel free to cut-and-paste this into a file and use it for yourself. Note that I have tested this script on multiprocessor machines, and it works correctly, with one important word of caution... run one instance of this script for each CPU, and make sure they each use completely separate sets of client instances.

#!/bin/sh # before using this script, create as many instances of SETI as # you want to use, each in its own subdirectory off of your main # seti directory. make sure to log into each one (start it, give # your email address, get a workunit, then stop the client.) # then, just run this script, from your base seti directory, with # the name of each instance you want to use. so for example, if # you name this script "seti.scr", and create directories named # "/seti/sah-1a", "/seti/sah-1b", and "/seti/sah-1c", you would # invoke this script from the "/seti" directory as: # "seti.scr sah-1a sah-1b sah-1c &" # also, note the default directory ("BASE") and priority ("OPTS"). # you may wish to change these (unless you just happen to run # your clients in the directory "/home/pla/seti/whatever"...). BASE="/home/pla/seti" OPTS="-nice 18"
sendone() { echo; echo; echo trying to send $1; echo; echo cd $BASE/$1 ./$1 $OPTS -stop_after_xfer & sleep 3 if kill -0 `cat pid.sah`; then sleep 30; fi if kill -0 `cat pid.sah`; then sleep 300; fi kill `cat pid.sah` cd $BASE echo; echo; echo done trying to send $1; echo; echo } procone() { echo; echo; echo processing $1; echo; echo cd $BASE/$1 ./$1 $OPTS -stop_after_process sendone $1 cd $BASE echo; echo; echo done processing $1; echo; echo } while test $# -ne 0 do for I in $@; do for J in $@; do sendone $J done procone $I done done echo "no instances specified"

Note: SETI@home recently requested that people running such scripts put in delays of several hours before retrying the connection. however, the client itself will retry every hour, so that seems like a stupid request. If you want to make the above script more "friendly", after the lines containing "sleep 30" and "sleep 300", add a similar line containing "sleep 3000". That will, in the event the client has trouble returning or receiving a workunit, wait a total of 55 minutes and 33 seconds before proceeding.









This page has received 05524 hits.