SETI@home is the Search for Extraterrestiral Intelligence implemented on
home and business computers. An article about it in the 7 June TIMES
inspired me to download the software from setiathome.ssl.berkely.edu,
install it, and get my first Work Unit. My computer now crunches away,
when it is otherwise idle, on some data from the Aricebo space telescope,
looking for a "signal" in a little patch of sky in a little band of
frequencies. The sky and the spectrum are so vast, not to mention possible
signal characteristics and doppler effects, that SETI scientists now have
over 5000,000 computer users analyzing bits of the signals - an amount of
effort that would have been impossible to support centrally. 

61 responses total.

I am running seti@home on a 120 MHz PowerMac, which makes launching and
running the software for background computation rather slow down other
applications. However it can also be run as a "screensaver" - it kicks in
when the computer is idle, and picks up where it left off. However the
screensaver mode requires a display setting of at least 800x500 pixels,
and I prefer running at 640x480. The screensaver mode refuses to run
unless I change the display setting to 800x600. There is no reason why one
has to display the "screensaver" at all, however (you can have it go to a
dark screen). I would like to know if I can set the software to run in
"screensaver" mode with any display setting. The background mode will run
OK with any display setting. 

(I am asking here first as others may have solved this problem, before
I ask the very busy people at SETI.)

If you are more concerned with crunching numbers than displaying
pretty graphics, under Windows you can get rid of about 2/3 of the
overhead by turning the screen saver off completely.  This will
get through a "work unit" in 13-15 hours compared to maybe 40 on
a PII 450.

As I said in #1, that slows down other application when seti@home is
running in the background - quite seriously, on this machine. That's
why I want the screensaver *mode* but not the screensaver or its display. 
I'd like the machine to crunch the numbers when my machine is on and idle,
without having to change the display parameters. 

On another aspect of SETI@home - I read somewhere, and was told again
today, that when this effort was started they didn't have enough data
ready for the very large number of enrollees, so sent the same data sets
to large numbers of people. Does anyone have any more particulars on
that? I didn't see anything about it on the web site.

It's more likely that their database machine had problems under the
unexpected load; they didn't think they'd have so many people enrolled
for about 6 months.  They're quite literally overwhelmed.

Sigh....my first work unit is only 19% done in 16 hours of CPU time. And,
there is no sign of ET.

I know one guy who is doing the same sort of thing out of his personal
observatory and has several Linux boxes linked together for number
crunching.  Another guy is running the "screen saver" on his Alpha.
I don't know how long it takes that to crunch out a set of numbers.

I've heard that the fastest supported OS/CPU combo is Windows/Alpha.
Something like 9 hours a work unit.  (Must not do any graphics.)

There are a lot of statistics about how many of each of the many CPUs
and OSs are running SETI@home, and how long each takes to do a work
unit, to be found at the website. 

At one time I studied and used some statistical information theory, involving
autocorrelations and power density functions, and all that, so read the
SETI@home technical description of the data and algorithms. It is pretty
impressive, but illustrates how many assumptions had to be made to define
a protocol. Here are a few of the technical aspects of the analysis.

The data are all from a 2.5 MHz spectrum band centered on 1.420 GHz. It
is presumed that intergalactic communications might be near the 21 cm
hydrogen line (at ca. 1.428 GHz).

(I have to go off line - to be continued.)

Elementary SETI - continued.

That narrow-band (2.5 MHz) signal is downconverted to a lower frequency
and then digitized. It is then digitally subdivided into 256 sub-bands,
each 9766 Hz wide, and back converted to a digitally sampled time signal.
107 seconds of that 9766 Hz bandwidth signal constitutes a "work unit",
and is what is downloaded to your machine.

It takes 12 seconds for a stellar radio object to traverse the focus of
the Arecibo telescope and the signal strength received would look like
a Gaussian curve. This is what is looked for in the data. The problem
are:

1. The bandwidth of a signal transmitted by ETs is unknown.
2. The signal received is doppler shifted and degree of doppler shifting
   can be continually changing, because the source may be accelerating
   or decelerating along our line of sight as it (say) swings around a
   star.
3. The signal may be modulated. 

The data in a work unit are therefore analyzed *thousands of times*
assuming different bandwidths (starting at 0.07 Hz), different 
doppler accelerations (in steps of 0.002 Hz), and different pulse
rates (the assumed simplest modulation). 

The analyses are done with a technique known as Fast Fourier Transform
(FFT), which spreads out the 9766 Hz wide band and measures the power in
the chosen bandwidth intervals, for different time intervals in the 107
seconds of data. Each bandwidth interval power is fitted with a Gaussian
curve, and the quality of the fit is calculated and stored.

So far, one (1!) "highly" significant Gaussian signal has been detected in
all of the work units that have been done. They will go back and look
again, and also run tests to detect if it could have come from a
terrestrial source (terrestrial sources won't fade in and out with those
12 second reception windows).

The fastest computer/OS combinations do a work unit in ca. 9 hours of CPU
time. I'm up to about 37% of a work unit done in 37 hours of CPU time
(with a 120 MHz computer). It's been fun, but I think I better leave this
effort to faster machines. 

Doppler accelerations would be in units of Hz/second.

Don't give up just because your machine isn't moving too fast; every
bit helps (pun unintended).

It might not be so much the operating system, as it is the software for
each particular operating system.

Yes, I made a type for doppler acceleration units - Hz/s is correct.

I'm doing my bit(s).

My work unit is now 56.5% complete - after 60.5 hours of CPU time. The
computation rolled over from positive to negative doppler accelerations
at the half way point. The doppler accelerations are, incidentally, called
the "chirping rate". It suddenly struck me why, as the doppler acceleration
is applied to the data - not to the spectral transform. That is, the
time-series data are "chirped" by transforming the time base. This would
make a single tone sound like, well, a "chirp". In cosmological terms,
the data are now being analyzed as though the source was accelerating
away from us, instead of toward us. 

One is struck by the idea that what is needed for analyzing these data
is a *brain*, not a computer. We are able to "hear" single notes of a
flute in the midst of all the sounds of an orchestra. Consider, though,
that what a microphone picks up from an orchestra is a single varying
voltage (or two such, if we do it in stereo). How would we go about
picking out just the chirp of a flute in that by means of a computer?

Perhaps it would be useful to also just listen to our 107 seconds of
10 kHz bandwith work-unit noise. 

First work unit finished at 110 hours CPU time. ET wasn't home. This
machine is too slow for efficient processing, though I have started on a
second work unit. When you are done, and if you are not on a LAN
permanently, you click on SEND, and the program connects, sends the
results of your work unit to Berkely, and then downloads a new work unit.
(They do say if you don't finish in a reasonable length of time - unstated
- they send that work unit to someone else). 

I loaded SETI@home into our daughter's iMac, a G3 processor machine. This
did a work unit in 27 hours (while the PowerMac is still grinding away).

I'd like to suggest that GREX join the project. The program is available
for unix machines, and Grex is connected to the web, so it could
be automatic to start another work unit after finishing one. The
results for each work unit (as Gaussian power and chi-sqare "fit")
could be posted regularly. Grex might be the first to get a call from
ET! I do not know, however, how it would be set up to run in background
and not take a significant part of the overall CPU time. What do you
think?

SETI@HOME doesn't distribute source.  I doubt they have a binary
for Grex's ancient hardware.

They offer binaries for some 50 different unix and other systems.

Actually many users have brought SETI@HOME to Grex in an attempt to soak 
up our "spare" cycles. The grex staff generally is not happy to see this 
done on Grex. Marcus summed up our thoughts as to why this is in 
resp:coop,108,28

That triggers an update - my daughter's iMac has now done 58 work units,
in between her homework. No strong gaussians have been found in these. 

What's been happening with SETI@home? Have any signals been  detected
that are being investigated in detail as being possible alien signals?
How big is the program currently? 

(I stopped running it as my computer was too slow, and my daughter
took her's to college. But my new computer might be useful to crunch
ore signals.)

They have something like three dozen signals that are being 
investigated more closely, last I heard.  There's a certain amount of 
work that has to be done 'by hand' to weed out interference from 
terrestrial sources and satellites, once most of the data has been 
discarded by the distributed analysis.

Right now they appear to be having server problems; my machine's been 
trying for about three days to return a work unit and download a new 
one, with no success.

I'm running SETI@home on my work computer, as a screensaver.  At home I 
was already running the distributed.net clients on both of my machines, 
when SETI@home started, and I've kept that up instead.  (RC5 
exclusively on the slower but always-on machine, a combination of RC5 
and OGR on the faster but not always on desktop.  OGR seems to be a lot 
more computationally intensive, and the slower machine just didn't make 
much progress on it.)

Is anyone participating in that distributed computing project to find a 
new anthrax drug?

Start an item and tell us about it. Distributed anthrax, huh?

The site's here: http://www.chem.ox.ac.uk/anthrax/

I'm not running it (no machines left with spare clock cycles!) so I 
don't really have enough information to start an item.

Items are cheap. Start one with that URL so we can discuss anthrax
on earth, not in the Andromeda Galaxy.

See item #77.

I have completed one work unit on this 533 HHz G4 and it took a little
over 12 hours, running in screensaver mode.  On my old PowerMac 120 a work
unit took 110 hours. I also now notice very little slowing of other
applications, or of grexing. 

The same excitement isn't there for me, as back in 1999 when the SETI
program was beginning. I think this is in part because after after
ca 3 years of this distributed crunching no alien signals have been
found. It is true that only a *miniscule* fraction of the sky and of
the spectrum have been searched, and then only in a  miniscule variety
of modulation modes (there method would not detect spread spectrum
modes, for example). 

But since this processing can be run in background, and there is a  LOT
of otherwise idle time on computers worldwide, the thing to do is just
start this thing on more computers and forget about it until the bell
rings...... 

Also, as the information about the project points out, if there were an
identical project being run by aliens with the same technology we have, it's
very likely that they'd be completely unable to detect us.  It's a real long
shot that we'll find someting, even *if* there's another intelligent race
out there.

I just received a CERTIFICATE ("suitable for framing...sorta) on completing
my 100-th work unit. As I mentioned, I just run them in background and
I find no noticeable slowing or interruption of anything else I do on
this computer. In fact, I'd like to find out how to have SETI start
on bootup (so have asked them). There does not seem to be an extension
per-se that I could alias and put in the startup folder (on this Mac G4).

Still no definite alien signals - the situation is much like David described
in January - more signals have been analyzed in detail and found to be
earth-based, while additional ones are being processed. Several new
analyses have been introduced since last year, but I don't recall what
they are (sorry...).

I'm continuing here the inquiry I started in #77 (distributed computing),
since this is the SETI item alone. Here's where it stands:

SETI on a Mac can be run as either an automatic screensaver or launched
manually. I don't like what some of the screensaver mode does (to other
screensavers, etc), and would just like SETI to launch automatically
on startup. I asked about how to do this in #77; sent e-mail to
SETI.org to ask (no response); tried to use the  Applescript editor
to create a script that could be put in the Startup folder (but 
the Applescript editor would not record these); and searched the web for
a (free) utility that would create a macro to do this (without success).

Does anyone here know how to create such a startup script?

Have encountered my first "short" workunit (on about # 347) - 34 minutes. 
My average work unit time is just under 10 hours. "Short" units occur when
there is a very strong signal from an earth source in the work unit. I'm
not sure how this makes the whole unit not worthwhile to complete, since
there still might be weak signals nearby.

Front end overload?

Here is the explanation from SETI:

"Occasionally, a work unit will contain strong radio interference; these
strong interfering signals typically come from satellites and radar from
our own civilization. If the interference is very strong, the SETI@home
program can not analyze that part of the spectrum, and after trying for a
few minutes and detecting thousands of strong signals of earth origin, the
program stops early in the processing and gets a new work unit. You will
still get credit for the work done." 

That's not very specific. I think, though, it might be because of a large
number of earth source overtones (harmonics) which cover the frequency
interval of interest too thoroughly to be able to identify a potential
ET source. The many close-spaced overtones could be produced from
intermodulation involving modulated broadcast and similar transmissions. 
Maybe.

I have just completed my 400th work unit. That puts me in 392,701th place
among 4,758,127 users. It sounds better as being in the top 8.3%. Average work
unit time has been 10hrs 50min 6.3sec. I run SETI in background when I
remember to turn it on. There are still no confirmed ET sources of narrow-band
transmissions - but of course you know that, as it would make all the front
pages if there were.

My computer at work has done 299 work units.  I never run in the
background, though, only in screen saver mode.

Run in background it suspends during other operations, so it causes no
apparent slowdown in other applications - but still picks up right away when
the computer is otherwise idle. This gets more done than using screensaver
mode.

I notice sluggishness due to the memory it's using.  My workstation
doesn't have a lot of RAM, so when SETI runs in the background it tends
to cause stuff to be swapped in and out as it gets and loses control of
the CPU.

After I have gone to running mostly Mac OS 10.3.2, I obtained the OS 10
version of the SETI app. I find that it runs at about 1/2 the speed of
running the OS 9 version: units used to take about 10 hours; now they take
20 hours. I haven't tried running SETI under Classic, to compare the speed
there.

Are you running it as a background application?  If so, it's probably a
difference in how the CPU scheduler works.  BSD is pretty aggressive
about taking the CPU away from low-priority jobs when something else
needs the CPU.

I'm running it as background. But it is on for long periods when I am not
at the computer, and it is just as slow when it is the only thing (overtly)
running. Is the CPU scheduler making work for itself all the time anyway?

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss