Wirt writes:
> After you install the screensaver, the client dials Berkeley and downloads a
> "work unit" (an approximately 10-50 second chunk of observational data taken
> from the Arecibo radio observatory in Puerto Rico earlier this year). My
> chunks have been relatively small so far (about 150K), but the processing
> times have been about 100 hrs.

I think the chunks are all supposed to be about 256K of data which is ascii
encoded with some header info which brings a "work unit" up to about 320K
or thereabouts.

> I have since discovered that it's important to go to the Control
> Panel:Display settings in Windows and set the screensaver to go blank after a
> few minutes. The pretty graphics are apparently more time consuming than the
> actual data crunching. By turning the graphics off, the computational process
> is sped up by about 4 or 5 times, reducing a chunk processing period to about
> 20 hours.

The Windows version currently appears to be at least twice as slow as the
Linux version for some reason.  During the beta, I was consistently taking
10 hours to process a work unit on either a PA-RISC server or my PC.  The
Windows version seems to want to take 20-30 hours even with the display
off.  I thus reboot into Linux at night on my PC and leave it running.

Since the restart/launch of the official project last Friday, they have
not released a new PA-RISC executable, and appear to be throwing away
results from the old client software silently, so I've only got it running
on my PC at the moment.

We thought about asking for the .o files for the PA-RISC version so we
could link a 3000 version, but figured that not too many people have the
spare cycles to burn on their 3000s :-)

> There are no disc transfers that I can detect.

I believe it's constantly "checkpointing" a small file on disk so that you
can kill it at any point and it will restart without loss of work.  There
is only like 256 bytes worth of data that has to be checkpointed in this
way.  At least this is the way the unix client works, Windows may be
different.

> I've been able to deduce from their data patterns that they send out the same
> "work unit" chunk to eight different client machines.

I believe that they are actually sending out different data to each user.
If you read their technical descriptions on the web page, they talk about
this somewhere.  You're only getting a slice of the bandwidth from each
segment, not the whole thing.  Their server keeps track of which work
units have not been returned, and will eventually farm it out to someone
else.  Wasting 7/8 or your processing power on redundant processing does
not make sense.  I believe they also insert test data occasionally
to make sure that the whole system is working end-to-end.

> The chance that this process will discover life other than our own is
> vanishingly small.

Of course lately astronomers have been finding planets left and right
around other stars, which certainly makes things look more possible.

On the other hand I recently saw a discussion that pointed out that
the period during which a civilization would be sending out things like
television signals (as opposed to signals explicitly meant for detection
by other civilizations) that we might detect is incredibly short.  For
example life on Earth has been evolving for several billion years, but
we only started sending out significant radio signals within the last
100 years.  And within 100 years of starting, we will have evolved from
low bandwidth, high power, regular signals that might be detectable to
low power, high bandwidth, spread spectrum type transmissions which are
almost impossible to detect at any distance.  So for SETI@Home to
succeed, they either need to get lucky and spot a civilization that is
at a similar level of development to ours, or (more likely) to see
signals that are explicitly intended for detection.

On the other other hand (This is SETI after all) there's a good chance
that the program will discover a number of new interesting astronomical
phenomenon, even if none of them are trying to phone home.

> The address to get started if you want to participate is:
>
>      http://setiathome.ssl.berkeley.edu/

G.