This month's most interesting messages:

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

Matt Lebofsky - 2000.05.02 in s.a.s./a.s.s., server status page inaccurate?

Hey. I wrote this program. How does it tend to be inaccurate? Actually, I know already one way. That is when we start up the server and we have a long period of "catching up" when everybody is trying to connect, so lots of people still can't get through. So the server is up and the server status page says so but a lot of users are still unable to connect. That's why I added the note that though the server is running we may be swamped with requests. I'd like to know if people found other cases where it is inaccurate.

BTW, I'll be adding more server status info to that page as time permits.

Eric J. Korpela - 2000.05.02 in s.a.s./a.s.s., when asked if the old data will be 'recrunched' with version 3:

The assumption now is that we won't be going through the old tapes again. We may eventually change our minds, but it's more likely that we'll just continue on with new data...

Eric J. Korpela - 2000.05.03 in s.a.s., when asked if data will be retrieved from archived tapes to confirm a signal found by the new pulse detection code:

Yes. It would be a fast way to do a confirmation without requiring use of a telescope.

Eric J. Korpela - 2000.05.05 in s.a.s./a.s.s., when asked to estimate the speed of version 3.0 and the duration of the transition period:

We're shooting for 15 to 25%, but it might end up as little at 10% longer than with version 2.0.

For the rollout of version 3.0, there [ >8 ] will likely be a shorter grace period than 2.0, but it's exact duration isn't known yet.

Matt Lebofsky - 2000.05.05 in s.a.s./a.s.s., the rollout of version 3.0:

We never did force an upgrade to 2.x, but will we definitely force the 3.x upgrade. Probably over the course of 3-4 weeks (starting with putting it on the web site without fanfare, then having the servers send polite messages about the upgrade, then more severe messages, and then actually rejecting results from 2.x and earlier clients).

Hiram Clawson - 2000.05.29 in s.a.s., all the version 2.* clients are exactly the same in all respects:

Each porter for every platform tries to get the best performance out of the client that they can possibly get with any compiler options that they wish to play with. They are not allowed to alter the code.

I personally port four of the x86 clients and I have tried several different compilers, with options for the various chipsets and I simply do not find any significant difference no matter how you compile the client. If I did, I would be the first to have special clients for the platforms that I port the client to. The client speed is limited by memory size and memory access speed.

If I allowed a 386, 486, 586, 686, 786, ... client for every Intel platform it would simply be too much work for the porters and myself to manage and the download page would be even more confusing to the vast majority of users who don't even know what chipset they have. Especially since all that work doesn't buy you anything at all.

Hiram Clawson - 2000.05.29 in s.a.s., Re: overclocking:

I note this information in the FAQ at the distributed.net site:
http://n0cgi.distributed.net/faq/cache/148.html

That is interesting that a single error by an overclocked system could ruin their entire project. At least S@H has some redundancy to cover client errors.

Hiram Clawson - 2000.05.30 in s.a.s., overclocking and crosschecking:

I don't think the S@H project could say anything about overclocking good or bad. We all know that it happens and that is a fact and S@H can't do anything about that. Even without overclocking as a source of errors, other bugs in the system could be causing errors and thus the S@H project has to be aware that errors in processing can occur.

I am unaware of the details of the redundancy checking.
However from the progress graphs at
http://setiathome.ssl.berkeley.edu/graphs.html
you can see that the number of WUs generated: 4.7*10^7
is much lower than the number of WUs returned: 1.25*10^8
for a ratio of: 12.5/4.7 ~= 3/1
implying that each WU is processed about three times.