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