This month's most interesting messages:

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

Eric J. Korpela - 2000.06.13 in s.a.s./a.s.s., about the FFT used for version 3 of the client:

Actually it was a close race between FFTW and another fft. (I'm not sure of our licensing agreement for the other one and don't know if I can make the origin of it public, yet. It's not Intel, for those that are worried.) We found that the other one was a few percent faster on most platforms and had a much smaller memory footprint. The smaller memory footprint was a big selling point, especially on a certain architecture that has memory allocation schemes rooted in the stone age. For those guessing which one it is, it's initial isn't W.

From a programmer's standpoint I still prefer FFTW for its flexibility, and we will certainly keep using it in the splitters.

Matt Lebofsky - 2000.06.15 in s.a.s./a.s.s., presenting Eric Heien:

Eric Heien is an undergraduate student working for us - he should be up on the personnel page (and Peter and Leonard should be taken off). He's working full time over the summer (he worked part time for a while now) and helping catch up on a lot of web/science stuff. I'll even have him update the personnel page in his next free moment.

Eric J. Korpela - 2000.06.21 in s.a.s./a.s.s., about the 'unexplainable' spikes, the topic of Science Newsletter #3:

The reciever was providing signal and was functioning. The problem was that the colling system was malfunctioning allowing the reciever temperature to increase to the point where it was providing the recorder with garbage.

Usually we check the telescope engineering logs before we put the tapes in the splitter. These tapes just slipped by somehow.

A should point out, however, that the setiathome data recorder is just reading voltages on a couple of signal lines. Even if the receiver is off, or disconnected, the recorder will still read those voltages unless it is also shut off. In the case of disconnection the voltages tend to stay either positive or negative. The splitter can, and does detect this, and will skip over affected areas of a tape. A receiver shutoff is more difficult to detect, and a noisy malfunctioning reciever doesn't look much different to the splitters than a properly operating one does.

Hiram Clawson - 2000.06.27 in s.a.s./a.s.s., once more the bogus 'InTel paid-off SETI@Home' conspiracy:

Boy, I wish INTEL would give me some money to work on the client. Sorry, but there is no conspiracy involved. All the porters are merely volunteers and we receive no money from any source. Funds donated to SETI@Home are put to much better use than paying someone to optimize a client.

What happens is that each porter becomes more familiar with their compiler, or they find a better compiler in between versions and they learn how to use the compiler options better. That's all that happens between versions. All the clients are compiled from the exact same source, modifications are not allowed.

I should know, I manage all the UNIX porters.

Matt Lebofsky - 2000.06.27 in s.a.s., stats updating times:

For the record:

1) Domain/Team stats should get regerated every day, starting at around 4:00pm (this process lasts anywhere from 10-16 hours). 2) All other stats on the stats page (including countries) should be updated every 4 hours (this process takes about 1-2 hours).

Eric Heien - 2000.06.28 in a.s.s., a reply to a "What I think about S@H" message:

Thank you for posting your thoughts about SETI@home on the newsgroup, it is good to get occasional feedback so we know what to improve on. First of all, let me thank you and every other SETI@home participant for the time and effort you have put into the SETI@home project. Although we may not say it often enough publicly, we do greatly appreciate all the people who have volunteered their computers and time for the project.

I'll try to answer some of your comments and explain our reasoning behind some of the things we have done that you have complained about. First of all, at the core of SETI@home, we only have 8 scientists/programmers, 5 of which are actually involved in other projects as well and not able to have a full time commitment to SETI@home. When the project was initially founded, it was expected that 100,000 people would sign up, if we were very lucky. Needless to say, when we reached the one millionth user only 3 months after the project began, we were overwhelmed. We have spent a great deal of effort trying merely to keep the servers able to handle the incredible load we are experiencing.

Unfortunately, this combination of few programmers and many users means we are unable to devote a great deal of time to optimizing the client code and adding additional scientific analysis to the client. Initially we were going to put in a faster FFT routine, but were unable to get the required licence for it. In addition, many optimized FFT routines run faster on certain platforms than others, and we do not want to favor a particular platform in workunit processing speed.

SETI@home is first and foremost a scientific endeavour. Therefore, we chose not to support the speedup patches that came out because we felt they could damage the scientific validity of the project. This was especially true since the author would not even let us see what optimizations he had made, making it entirely possible the patched clients were returning incorrect results. If the author had been willing to share the source code of his patch, we may have been willing to implement it into the SETI@home client.

Again, thank you for your input about the project and time spent on analyzing data. Hopefully this letter has answered a few questions you and others have had about SETI@home.

Sincerely, - Eric Heien

Eric Heien - 2000.06.29 in a.s.s., about the conclusion in Science Newsletter #4:

One of the basic rules of scientific experiments is that the results are repeatable. So along the same lines, if a signal is seen in some place in the sky, it's a good idea to check the same place again later to make sure the signal is still there and not just the result of background noise. Since Arecibo will scan the same place in the sky several times over the course of the project, if a gaussian/spike is found at the same place at different scanning times, it is grounds for suspecting a possible signal.

The reason the rest of the sky around that signal is checked is to make sure that the signal wasn't RFI. If it was a valid signal, it would only appear as a single dot on the plot, since that is how long it takes the telescope to sweep over a single spot. If the signal is found repeatedly over a long period of time, it is impossible for the signal to be coming from anyplace but Earth or it's immediate vicinity (unless Arecibo is constantly aiming at a specific location in the sky, but SETI@home does not analyze data taken at these times). So the signals that are seen for a lengthy period of time are ruled out as RFI.

Eric J. Korpela - 2000.06.29 in s.a.s., why during certain periods, there are no gaussians to be reported:

That usually means our feed was tracking during the work unit. If our feed is tracking the same point we can't look for gaussians.

Eric J. Korpela - 2000.06.30 in a.s.s., Error - "Attempt to send duplicate result":

At some point today the database started thinking every result was a duplicate. It looked like another screwed up index, but regenerating the table and index involved didn't solve the problem. We've temporarily gone back to the old method of duplicate checking until we get this problem fixed.

Sorry for the inconvenience.