This month's most interesting messages:

All from the SETI@home team members at Berkeley. Non-official statements but interesting anyway.

Eric J. Korpela - 1999.12.02 in s.a.s./a.s.s., on sending back duplicate results (without giving enough info to break their security measures):

1. We detect duplicate results using two methods, one is immediate but only works for duplicate results sent with a certain time period, the other is delayed and finds all duplicate results. It's running quite a bit behind schedule, but should catch up with the new servers.

2. There are two other checks that detect the 'header modification' method, again one is immediate, the other is delayed.

Eric J. Korpela - 1999.12.03 in s.a.s./a.s.s., when asked for the policy on when a fast WU is counted or not:

I could have sworn it was 60 seconds (due to the Macintosh version 1.5 bug), but looking at the source code it is now 600 seconds. I'm suprised it's that long. Ten minutes is a long time. I'll ask David when, and why, that change was made.

Eric J. Korpela - 1999.12.04 in s.a.s./a.s.s., when an off the record question was asked about the chances of S@h finding something:

Off or on the record I'd give about the same answer: somewhere between 0.5 and a few percent per year of operation. At levels like this we're probably roughly linear in badwidth and sky coverage. Double the bandwindth (add another recorder) double the chances. Double the sky coverage, and you don't quite double the chances, because there isn't a sourthern hemisphere telescope as large as Arecibo. Add pulse detection and you probably haven't doubled thei chances.

I don't think anyone has guaranteed a detection, that's the way it is in science. Guarantted payoffs don't change the world, the long shots do.

Eric J. Korpela - 1999.12.06 in a.s.s., about the test signals:

There are 3 test signal frequencies in the setiathome band that are inserted at periodic (calculable) intervals. These signals are actually inserted into the RF data well upstream of the SETI@home data recorder. The main reason they are there is to test the time and frequecy accuracy of the instruments.

Eric J. Korpela - 1999.12.08 in a.s.s., about changing the gaussian scores:

Actually, revising the scoring criteria for gaussians is on my list somewhere. It is too much in favor of both 'poor fit/high power' and 'low power/good fit' gaussians. Ones with moderate fit and moderate power never end up on the list. (Basically the list is just the top right and the far bottom of the 'interesting region' plot at http://setiathome.ssl.berkeley.edu/gaussian_graphs.html )

Eric J. Korpela - 1999.12.09 in a.s.s., with more about changing the gaussian scores:

The high power/poor fit candidates are almost certainly RFI. The low power/good fit candidates are likely to be random noise. (After all random noise has a fit of 1 for a gaussian amplitude of zero.) That said, a true ETI is likely to be mixed in on the low power/good fit end of the spectrum, so we can't just discount them out of hand. I may play around with a power/chi^4 scoring just to see what it looks like.

Matt Lebofsky - 1999.12.13 in s.a.s./a.s.s., about patching:

SETI@home doesn't allow unauthorized access to our data server. Patched clients which look like real clients that contact our server could, in theory, do any number of things that cause harm. In short, it's a form of hacking.

Of course people believe the patch is safe and accurate. We here at SETI@home don't know that, nor has the patch creator been willing to prove it. The author of this patch even goes as far as to completely *refuse* to identify his patch so our server can recognize it as a patched client. To me, this is an obvious affront.
In short, we can't tell if results are from patched clients or not. The patch could easily be modified to fix this. It hasn't been. Case closed.

Eric J. Korpela - 1999.12.15 in s.a.s./a.s.s./alt.info-science.seti, when asked about the newsletter:

Everyone should get it at the email address of your setiathome account. It's our first mass mailing (which we do with quite a bit of trepedation). And yes, there is a way to unsubscribe. At any rate we won't flood anyone's mailbox, we'll be sending out status reports every 6 months or so.

Eric J. Korpela - 1999.12.15 in s.a.s./a.s.s., answering the question from an add-on developer, if the format of the *.txt files will change in V.2.0:

The biggest change is that they will no longer be .txt files. They will be .sah files (to get around the virus scanners that have been locking .txt files in order to scan them.) The gaussian report format has some extra information. Other than that they should be little changed. There also may be some additional header lines.

Eric J. Korpela - 1999.12.17 in s.a.s./a.s.s./alt.info-science.seti, about the suggestion of including a way of adjusting disk-write intervals into the client:

We're working a fix to this (a selectable update time), but it didn't make it in before the 2.0 feature freeze. :(

Eric J. Korpela - 1999.12.17 in s.a.s., answering the question as why S@h doesn't try to get permission to piggy-back on other telescopes:

We're working on it.....

Eric J. Korpela - 1999.12.19 in s.a.s.:

We would certainly like to do searches for pulsed signals. In fact 2.0 would have contained pulse search algorithms had not the bulk of our programming effort been diverted into making a client that was difficult to patch. Alas, pulse detection will have to wait for a later revision of the client.

Eric J. Korpela - 1999.12.20 in s.a.s., when asked about priorities and if a second recording system was a high priority:

I think it's probably one of the most important priorities. I don't think it's been decided whether a second recorder would go on Arecibo to allow more band coverage or if it would go to a second telescope, for more sky coverage. The first option might be less expensive. The second would probably be more interesting.

Other things high on the priority list: development of a pulse finding client using FFTW, science post processing so we can have click-through links about the top gaussians and spikes saying how many times they were reported, whether they are likely to be RFI, how many times that area of sky was searched, etc.

Eric J. Korpela - 1999.12.22 in a.s.s., talking about patching:

Earlier [ >8 ] I have indicated that the pulse finding client will use FFTW, which is faster than [ >8 ] the patch and [ >8 ] platform independent.

Beefing up the science package WAS, in fact, held up by the patch developments. Without the patches, there would have been little reason to advance the next release version (which was mainly for SOCKS support and minor bug fixes) to the status of a major release.

Hell, I'm the one working on the pulse detection algorithms. I think I would know both what is driving our development efforts, and at what point we switched tracks. There was no point in speeding up the science without adding pulse detection. And pulse detection wasn't ready when the patches started surfacing. Because I got diverted, pulse detection sat by the sidelines.

The patches did not drive science development as we had already selected candidates for optimized portable FFTs at that point.

Matt Lebofsky - 1999.12.22 in s.a.s., wanted an open socks4 proxy:

Pretty much the main bottleneck holding up completion of testing SETI@home version 2.0 is having free access to an open socks4 proxy.

Eric J. Korpela - 1999.12.23 in a.s.s., talking about the development of the 2.0 client:

[ >8 ] the SOCKS support, that was others. I did get diverted to anti-hacking code, especially on the server side, since I'm the defacto Informix DBA. The FFT algoritm selection was a group effort and not all that difficult. We looked at what had been submitted to us (which didn't include Olli's stuff as we were unaware of him at the time) got rid of anything that wasn't portable, tested the rest and made a decision, all the time wishing we could use FFTW. It wasn't until a couple weeks ago that the authors of FFTW convinced MIT to give us permission to use FFTW, (I don't know if we've recieved written permission yet).

I'm one of three people involved in real time operations. I do most of the database work tracking down hackers and marking their results as invalid. My position as liason to the newsgroups is unofficial. And, of course, I'm only (in theory) putting in 20 hours a week on SETI@home, and 20 a week on my other research. (Of course it usually turns in to much more than that on either.)

The pulse finding is the bulk of the development. To do the pulse finding with the highest sensitivity possible and covering the full parameter space (frequency, bandwidth, chirp rate, pulse period, pulse duty cycle) available in the data set, a work unit would take about 30 months to complete on a 450 MHz machine. Obviously we're not going to search the entire parameter space available. The idea is make logical choices at paring down the parameter space, setting uniform detection thresholds (false alarm rates) throughout the bulk of search region, etc. There's a lot of math in there, especially in understanding our sensitivity to signals that fall outside of 'deep search' parameter space. Our end goal is to have our new client take about the same total time as the current client does.

Eric J. Korpela - 1999.12.23 in a.s.s., new in the 2.0 client, a more detailed picture of the gaussian signal:

[ >8 ] the spike and gaussian power meters have been replaced by a 2D graphic, which most of the time is the best gaussian yet found in the work unit. The only time it's not is during the actual curve fitting at which point it plots every gaussian above a certain threshold.

The Christmas present/joke of Eric J. Korpela - 1999.12.24 in a.s.s.:

Eric: [ >8 ] "I put a Christmas present/joke into the slow splitter. Let's see if someone notices before Monday."

One hour after Eric's posting, Ann Hughes was ready to tell everybody what it was. Eric: "Feel free.... The chances of getting one is pretty small."

In the end, at least 12 people in the newsgroups got one.

Matt Lebofsky - 1999.12.27 in s.a.s., about the server outages:

I'm thinking sometime this week I'll write a cron job that generates a 'server status' page every five minutes. And the new client will tell people to refer to the webpage for more info if it seems like a server-down problem.

Eric J. Korpela - 1999.12.29 in a.s.s., about candidate signals & positive results:

[ >8 ] the terminology. At this point none of the candidate signals are what we would call 'positive results.' They are candidate signals that have a lot of processing to go through to reject RFI, etc. At any rate the bulk of the duplicate processing is not to check the candidates, but to verify that we arean't missing candidates. The most likely error and the most likely fraud is a null result, not one containing candiates.

Eric J. Korpela - 1999.12.29 in a.s.s., server status page:

We're in the process of adding a page to the web site. It's currently at http://setiathome.ssl.berkeley.edu/sstatus.html and will eventually be linked into the home page.

Eric J. Korpela - 1999.12.30 in s.a.s., about how many people run the day to day S@h project:

Make that four half time employees.

Eric J. Korpela - 1999.12.30 in a.s.s., dealing with the Y2k rollover:

We're just going to let it ride. We think we're all patched up and ready to go. Barring power outages and network failures downstream from us, we should work continuously.