This month's most interesting messages:

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

Matt Lebofsky - 2000.02.01 in s.a.s., informal policy about downloading from the ftp mirrors:

We built a version 2.01 and placed it on our local ftp site on Friday so that our ftp.cdrom.com mirror could pick it up. Due to the onslaught of anxious downloaders one of our local ftp mirrors kept crashing over the weekend so cdrom.com never got it. But that is okay, since there are a couple bugs that got uncovered and soon enough there will be a 2.02 version.

Anywho, since there hasn't been a formal policy about our support for 'unreleased' yet 'available' versions, I planted a first crack at a README file in the ftp download directory, and pasted it below.

FYI, known bugs being fixed in 2.01 include the windows bug that result file sizes are growing out of bounds. Other bugs (like the screen blanking bug or the WU returning to 0%) we have been unable to reproduce here at the lab, but we're looking into it.

README on mirror sites 1 / 2 / 3 / 4

The SETI@home web site is the _only_ official source for released versions of the client. Recently, other sources have linked people directly to one of our FTP mirrors, where we put pre-release versions in preparation for making them available through our web site.

We are not opposed to direct downloads from this FTP server, but:

* Be aware that while all of the clients are "available" some are not yet 'released'. All released versions are linked to via our website. The remainder are simply available. In some cases, these may be transitional builds and so may be supplanted by later versions before they are released; in other words, some of these versions may never be officially released. Use them at your own risk!

* We do appreciate the feedback via the sci.astro.seti news group or via our web site if you find bugs or problems, especially in the first few days after a new version is posted on the FTP server.

- the SETI@home team 02/01/2000

Hiram Clawson - 2000.02.07 in a.s.s., releases? "Here's how it works."

I don't place anything on the FTP server until I know it has passed the test cycle. I let it sit there a day while it mirrors to CDROM. In a very rare instance, someone on the team will come up with a last minute bug, and we will either pull the version off the FTP directory, or update it with a fixed binary. This should not happen unless something horribly goes wrong.

After about 24 hours, I generate the unix.html WEB page, and the binary appears there.

I do not expect to put anything on the FTP site unless we believe it is OK.

The Win/Mac GUI clients have many many more beta sites than the unix clients, and they are tested much more thoroughly. However, they are much more complex than the unix clients, and therefore can undergo a few more cycles as last minute bugs are found. I don't actually have anything to do with the release cycle of these clients except for the fact that I am one of the beta sites.

Eric J. Korpela - 2000.02.07 in alt.folklore.computers, when asked who they did consult on the new security model:

[ >8 ] we did consult several cryptographers and security experts. Some are well known. If they wish to advertise their participation, that is for them to do. I guess most would prefer the fact that they gave no-cost consultations a secret, lest they be inundated with requests.

Eric J. Korpela - 2000.02.07 in alt.folklore.computers, about FFTW and optimizing (incl. a few hints about v3 of the client):

I presonally wrote very little of the Version 1.X and 2.X client. My part of that was mainly bug fixes. I did most of my work on the server side (where we use FFTW to generate work units).

FFTW doesn't actually have any processor specific code. In order to use 3DNow! or SSE instructions, the compiler has to generate them. And despite my requests, no one has donated a 3DNow! capable compiler. The only optimizing compiler that I'm aware has been donated to us is Intel's. (It's possible we have an optimizing Mac compiler, I don't deal with Mac stuff... And I know that a 686 optimized version of GCC is used for linux clients.) Once 3.0 is out, and my workload eases, I probably won't have a problem building optimized versions. For other systems, our porters use the compiler they have.

Assuming all of the processing time was in the FFT and assuming [ >8 ] using [ >8 ] assembly code, [ >8 ] a significant speed increase would be achieved. [ >8 ] The FFT is, IIRC, about half the time on most machines. But it's written in portable ANSI C and C++. That's the way it will likely stay. Fortunately, there are some decent FFTs written in C. Ver 3.0 isn't too far away.

Matt Lebofsky - 2000.02.08 in s.a.s./a.s.s., "Can you help us debug?"

We have had reports of several problems with SETI@home version 2.0 for Macintosh and Windows, which we have been unable to reproduce here at the lab. We hope that some of these are fixed with version 2.02, which is now available through our web site.

If you experience these bugs with SETI@home version 2.02, but successfully ran SETI@home version 1.06 (or older) without these problems, we would appreciate getting whatever details you can provide.

Please be sure in each case to tell us:
 - What platform you are running (Windows or Macintosh)
 - Which version of the OS are you using (Win95, Win98, WinNT, Mac OS7,
   Mac OS 8, Mac OS 9, etc.)
 - Are you connecting through a proxy server? If so, what kind (Microsoft
   Proxy, HTTP Proxy, SOCKS Proxy, a 'transparent proxy', etc.)

The bugs are:

 (1) Crashes or Illegal Operations on Windows using v2.02, but no problem
     with version 1.06.
   - Does this happen at a specific time (for example, when completing a
     work unit, when trying to connect, etc.)?
   - Does it happen only with certain work units? (Try saving a copy of
     each work_unit.sah file before it completes, so you can go back and
     retry it if some work units cause the problem and others don't. If
     it is work-unit-dependent, we may email you to ask you to mail us a
     problematic wu.)

 (2) Can't connect to Internet or to server with Windows v2.02, but no
     problem with Windows v1.06.
   - Does it work if you first connect to the Internet manually (via
     Dial-Up Networking)?

 (3) Can't connect to Internet or to server with Macintosh v2.02, but no
     problem with Macintosh 1.06.
   - Does it work if you first connect to the Internet manually via
     FreePPP, OT/PPP, or Remote Access (for OS 9)?

 (4) Windows screensaver v2.02 always shows a blank screen, even if
     'blank screen after xx minutes' is turned off.

Thank you all for your help and support. - Matt + the rest of the SETI@home team

Eric J. Korpela - 2000.02.08 in s.a.s./a.s.s., about gaussians shown versus recorded in v2.0x:

Actually gaussians with a power below 3.2 were never recorded. [ >8 ] In order to be recorded two things must occur. The power must be greater than 3.2 and the fit (chi_sqr) must be less than 10. High power gaussians with fits of 12 won't be recorded. Gaussians with fits of 5, but powers of 1.5 also will not be recorded. There has been no change in these thresholds from the 1.XX clients to 2.XX clients.

The increase in the number of gaussians found is probably due to a change in the amount of low intensity RFI in the data. The number of gaussians found per result has been pretty variable over the course of the project while the number of spikes has remained fairly constant. It's possible that certain parts of the sky have an excess of high power broad band sources that could show up as gaussians.

Eric J. Korpela - 2000.02.09 in s.a.s./a.s.s., about the 'interesting region' for gaussians:

There is [ >8 ] a difference between the gaussians we report and the gaussians which are 'interesting' by some definition of the word 'interesting'. We are reporting gaussians that are on the tail of the distribution of what would be expected from noise. What the web site calls the 'interesting' region represents the tail of the tail of the distribution. They are the real outliers, perhaps unusual in some way. There won't really be a difference between how we treat the gaussians that we get, whether they are in the 'interesting' region or not. They will all go through the same RFI rejection processes. It could be that all the 'interesting' events will be rejected in the first round. It may be that ET lies in the 'uninteresting' region... So we'll put all the signals through at least the first rounds of the analysis.

Eric J. Korpela - 2000.02.09 in s.a.s./a.s.s., about gaussians shown versus recorded (additional):

[ >8 ] I had forgotten that our threshold is 3.2 in units of what we call 'true mean power' and is integrated over the gaussian, whereas the reported power is the peak power or the gaussian. So the conversion between true mean power units and the reported units depends upon the width of the gaussian.

Sorry for the confusion.

Eric J. Korpela - 2000.02.09 in alt.folklore.computers, the speed of the patch:

If I had my choice I would have delayed 2.0 until the new science code was ready.

The [ >8 ] patch as tested doesn't even come close to doubling the speed of the client. 15-25% is what our tests show. It basically makes the 1.06 windows client run at the speed of the 1.3 linux client.

Eric J. Korpela - 2000.02.09 in alt.folklore.computers, the sky coverage and future of S@h:

Since we have no control of where we point, 3-4 times is a median coverage. Some parts of the sky will only be covered once at that point, some points will have been covered 20 times. We do use multiple detection as one of our criteria for marking events as interesting. Increasing the number of times you cover the sky increases the sensitivity to lower duty cycle signals. Once we are done with this, we are considering a second survey at another frequency with wider band coverage or going to another site to look at a different portion of the sky that is inaccesible from Arecibo. Of course, this is all contingent on raising enough money to do so. The amount we need to raise in order to finish the two years of the current survey is in the 6 figure range. To do follow-on survey would require much more in funds and equipment.

Matt Lebofsky - 2000.02.09 in s.a.s., Mac bugs in 2.02:

FYI, here are a couple bugs we know about iin v2.02 on the Mac. We're still looking into all the bugs I mentioned in an earlier post.

Macintosh v2.02 - On some computers running systems 7.x or 8.x, the SETI@home Preferences file and SETI@home Data folder are moved out of the Preferences folder to another location on disk when the computer is restarted. This causes new copies to be created in the Preferences folder.
This will be fixed in the next release A simple temporary workaround is to do a Find File for 'SETI@home Preferences' and/or 'SETI@home Data', then move the correct ones back into the Preferences folder (which is inside the System folder).

Macintosh V2.02 - We have had reports that SETI@home will not launch if an application which is part of Microsoft Office 98 is in the foreground.
We have reproduced this in our lab, and expect to have a fix in the next version. As a temporary workaround, move Word or Excel to the background when you want SETI@home to launch. An easy way to do this is to click on the desktop or select Finder from the icon at the right-hand end of the menu bar.

Matt Lebofsky - 2000.02.09 in s.a.s., by the way...

By the way, we will continue to accept data from the version 1.x clients until the version 2.x clients are stable and all major bugs are fixed.

Eric J. Korpela - 2000.02.10 in s.a.s./a.s.s., request:

Anyone out there willing to try 2.02 (Windows or Mac) on MS Proxy and/or IIS to see if any of the changes have made a difference?

Hiram Clawson - 2000.02.26 in s.a.s./a.s.s., apologizes for the not working of the upgrade warning for cli-clients:

I recently discovered that the currently existing command line v1.x and v2.x clients do _NOT_ properly warn users about a version upgrade. The Mac and Win GUI clients _DO_ properly warn users about a version upgrade.

I was hoping to give users a two week warning before turning off the v1.x clients. Today I begin the process of turning off the v1.x clients as indicated in the timetable at the end of the download page:
http://setiathome.ssl.berkeley.edu/unix.html

The first indication that users will know that clients need to be upgraded is that the v1.x clients will stop functioning. They will be unable to upload or obtain work units from the server. They will at least display a message:
'Must download new version of software'

I hope I can get this version warning thing fixed for any future releases.

Eric J. Korpela - 2000.02.27 in a.s.s., about requests for an optimized AMD compiler version with 3DNow!:

The SETI@home client is written in C and C++, and that's the way it stays. I've said it before, and I'll say it again. If AMD wants to send us a compiler that will generate AMD specific code, then they should get off their soft parts and do so. My mailbox is still empty...

At any rate we certainly aren't going to make a optimized port for every Intel compatible processor out there. Last time I counted there were 58 different x86 compatible processors out there to optimize for.

Eric J. Korpela - 2000.02.27 in a.s.s., version 3.0 news:

We've got the science portion of the pulse finding code integrated with a client and we're testing it now. What remains to be done is add graphical indications that pulse finding is taking place, some sort of display when one is found, and recalcuating the '% done' percentages. I'm on vacation for a week starting today, so 30 days from today might be a little optimistic, but it is possible.

Matt Lebofsky - 2000.02.29 in s.a.s., about the official release version of the new client:

A 2.03 is in the works. Fixes a lot of stuff. If all goes well, this will be the official release version, and 1.06 will phased out over the course of a few weeks - first the polite warnings, then the stern demands, then no 1.x results will be accepted.