1. Lessons Learned from SETI@home David P. Anderson Director, SETI@home Spaces Sciences Laboratory U.C. Berkeley April 2, 2002

2. SETI@home Operations data recorder screensavers science DBuser DB WU storage splitters DLT tapes data server result queue acct. queue garbage collector tape archive, delete tape backup master DB redundancy checking RFI elimination repeat detection web site CGI program web page generator

3. Radio SETI projects NameSensitivitySky coverage (%sky) Frequency Range (MHz) Max drift rate (Hz/sec) Frequency resolution (Hz) Computing power (GFLOPs) Phoenix (SETI Inst.) 1e-260.005 (1000 stars) 200011200 SETI@home3e-25332.5500.07 to 1200 25,000 SERENDIP (Berkeley) 1e-24331000.40.6150 Beta (Harvard) 3e-23703200.250.525

4. History and statistics Conceived 1995, launched April 1999 Funding: TPS, DiMI, numerous companies 3.6M users (.5M active), 226 countries 40 TB data recorded, processed 25 TeraFLOPs average over last year Almost 1 million years CPU time No ET signals yet, but other results

5. Public-resource computing Original: GIMPS, distributed.net Commercial: United Devices, Entropia, Porivo, Popular Power Academic, open-source Cosm, folding@home, SETI@home II The peer-to-peer paradigm

6. Characterizing SETI@home Fixed-rate data processing task Low bandwidth/computation ratio Independent parallelism Error tolerance

7. Millions and millions of computers Server scalability Dealing with excess CPU time Redundant computing Deals with cheating, malfunctions Control by changing computation Moore’s Law is true (causes same problems)

8. Network bandwidth costs money SSL to campus: 100 Mbps, free, unloaded Campus to ISP: 70 Mbps, not free First: load limiting at 25 Mbps Now: no limit, zero priority How to adapt load to capacity? What’s the break-even point (1GB per CPU day)

9. How to get and retain users Graphics are important But monitors do burn in Teams: users recruit other users Keep users informed Science news System management news Periodic project emails

10. Reward users PDF certificates Milestone pages and emails Leader boards (overall, country, …) Class pages Personal signal page

11. Let users express themselves User profiles Message boards Newsgroup (sci.astro.seti) Learn about users Online poll

12. Users are competitive Patched clients, benchmark wars Results with no computation Intentionally bad results Team recruitment by spam Sale of accounts on eBay Accounting is tricky

13. Anything can be reverse engineered Patched version of client efforts at self-checksumming Replacement of FFT routine Bad results Digital signing: doesn’t work Techniques for verifying work

14. Users will help if you let them Web-site translations Add-ons Server proxies Statistics DB and display Beta testers Porting Open-source development (will use in SETI@home II)

15. Client: mechanism, not policy Error handling, versioning Load regulation Let server decide Reasonable default if no server Put in a level of indirection Separate control and data

16. Cross-platform is manageable Windows, Mac are harder GNU tools and POSIX rule

17. Server reliability/performance Hardware Air conditioning, RAID controller Software Database server Architect for failure Develop diagnostic tools

18. What’s next for public computing? Better handling of large data Network scheduling Reliable multicast Expand computation model Multi-application, multi-project platform BOINC (Berkeley Open Infrastructure for Network Computing)