This month's most interesting messages:

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

Matt Lebofsky - 2000.01.08 in s.a.s./a.s.s., reporting on the beta stage of the 2.0 client:

We *think* we have the socks proxy stuff pretty solid now. The security stuff is already in place, as well as other bug fixes and minor enhancements. We're testing with a couple beta testers right now, will hopefully send out the full beta to the complete set of beta testers shortly, and if all goes well, yes, 2.0 may very well be available next week. I reiterate: 'if all goes well.' So don't hold your breath.

If 2.0 isn't ready any time soon we may stick the science code in. But that may be too much for one release. Chances are we'll release 2.0, let that soak for at least a couple of weeks, and then release 3.0 with the pulse detection code.

Matt Lebofsky has a dream - 2000.01.12 in s.a.s.:

I have a dream: Someday we'll have time to completely redo the web site, spreading it out over several servers, adding more functionality, adding more science and info... This will indeed happen at some point. Not tomorrow, though.

Matt Lebofsky - 2000.01.12 in s.a.s., explaining the generation of the stats pages:

[ >8 ] the stats pages aren't generated 'on the fly'. That would take *way* too much CPU time to query the database every time somebody checks the stats pages which happens about 3-4 times a second according to my logs.

There are several stats-generating cron jobs, the biggest of which is the one that creates the countries/domains/teams pages. This takes about 20 hours to do. And this runs every day. That leaves a window of about 4 hours/day that these pages are static. I believe I have the job start every day around 5:00pm so it works mostly during the night.

However, with several server reboots or crashes as of late, the cron job dies or quits in the middle, leaving the pages in a random state. Usually blank. This means you have until the next time 5:00pm PST rolls around *and* everything runs nominally for the following 20 hours before all the stats pages are up and working. Some of the stats pages are generated every four hours so you won't have to wait so long.

Eric J. Korpela - 2000.01.18 in s.a.s./a.s.s., explains the concentration of 'hits' on the top and bottom edges of the search area:

That's an artifact of how much time the telescope is spending searching each part of the sky. The way things are oriented our receiver will generally travel slowest (with repect to the sky) when it is near the north or south end of the range. Since we spend more time there, it's more likely that will get noise that looks like a gaussian there.

Of course, this also combines with the fact that the tracks that we sweep out when the dome is tracking an object are likely to cross at the ends of the range as well. In other words, we're likely to observe the same spot more often at the end of the range as well.

Eric J. Korpela - 2000.01.18 in s.a.s., when asked if with version 3 S@h will go through all the tapes again from the beginning:

[ >8 ] we haven't yet decided whether to do a re-analysis of old tapes for pulsed signals. That decision would probably come toward the end of the first depending upon our excess processsing ability and our recorder duty cycle at Arecibo.

Matt Lebofsky - 2000.01.18 in s.a.s., trying to find out about the 'Mystery Image':

[ >8 ] that image (?!) I sent an e-mail around to the group so somebody could clear up what that is. Probably somebody used /images as tmp space to test out a scanner or something. When I find out its origin/contents I'll fill y'all in.

I'll tell you this much: It's definitely NOT an alien autopsy (grin).

Eric J. Korpela - 2000.01.19 in alt.folklore.computers, if S@h is continually running in parallel with the other projects at Arecibo:

Actually, it's not that simple. With any electrical system there is the chance that its operation will interfere with the primary observations being done. If the primary observer wants us shut down, we most likely get shut down. There are also operation modes, such as planetary radar with which we are incompatible. When you add all this, and the down time from tropical storms, equipment failures, etc. you get a substantial fractional loss of observing time. For 1999, our duty cycle at Arecibo was less than 50% (or about 125,000 work units per day).

Matt Lebofsky - 2000.01.19 in s.a.s., uncovering the origin of the 'Mystery Image':

We had a SETI@home meeting today (where we discussed more important things) but I mentioned the mystery photograph and the origin of this photo is this:

David got an e-mail from somebody who claimed their computer at work (which was running SETI@home) and his photocopier were on the same network (I didn't realize photocopiers were network-able) and this image in question appeared on the photocopier for no apparent reason. So this person scanned in the image and sent it to David, and then he plopped it into the images directory so he could look at it via Netscape.

Nobody could remember if this image was sent as humor or as a serious plea for sudden attention. In any case, there you go. The mystery as to the origin of this photo has been solved.. But the mystery of why this image spewed forth from this person's photocopier remains, well.. a mystery. Mwha ha ha ha..

BTW, we get some pretty crazy e-mails sent to us, as you may very well imagine.

Eric J. Korpela - 2000.01.22 in a.s.s., about 'xsetiathome':

It's basically an X windowed version of the GUI. Consider it to be in an alpha state. One of the jobs I never got around to was to make an option to run it in the root window, so it could run in the background while you're working or used as an xscreensaver pluging.

It appears that we're going to release the source to xsetiathome, so someone else could do what I didn't finish, or add different graphics if they wanted.

The X window version runs under UNIX and Unix like systems. It gives users of those systems a chance to look at the graphics. Other than that, it looks as close to identical to the Windows/Mac version as we could make it.

Eric J. Korpela - 2000.01.22 in alt.folklore.computers, when asked: "Want to release the source? :)"

Sure, and have the couple hundred people currently sending us phony results start sending us phonies we can't detect. That would be real good.

I'm all for open source. There just isn't a viable security model in this case.

Eric J. Korpela - 2000.01.25 in a.s.s., the plot thickens, file under 'The @ Files':

Matt said he was going to post about this... According to David someone sent this image shortly after we released SETI@home. They claimed that after they started running SETI@home their photocopier spit out a page with that image on it. They claimed it was proof of alien life. Why David put it in the server image directory, I have no idea.

Hiram Clawson - 2000.01.26 in s.a.s., in 'the whereabouts of the v2.0 winnt-cmdline client':

The various ports filter in when the porters have time to do them. I have no control over when they arrive. I post them on the download page when they arrive. We are currently testing the winnt-cmdline client. Give it a few more days.

I take care of the unix porting business at S@H. Managing the porters.

Eric J. Korpela - 2000.01.27 in s.a.s./a.s.s., about the new display showing low power gaussians:

[ >8 ] we display gaussians at a lower threshold than we report them. We didn't want whole work units to run without anything showing up in that spot.

Eric J. Korpela - 2000.01.27 in a.s.s., whether the client should concentrate on the low negative chirp range, a little after the 50% point, where you would expect to find signals with only the earth's rotation and orbital chirps, or signals with corresponding chirps from earth-like planets:

Like any other object in circular motion the acceleration vector of the telescope is toward the center of the circle (i.e. a line from the telescope perpendicular to the earth's axis.) Therefore the best chirp rate for a non-accelerating source is going to be in the low negatives. And we could, if we desired, correct the data set for the earth's chirp rate as the first step. (It turns out there's really no difference between doing this first and doing it later.)

But, of course, we don't know what to expect from an ETI. Would they put large transmitters in orbit? Would they compensate their transmitters for rotational and orbital motion? Is their planet a fast rotator? Do they run their transmitter at a positive chirp just to make it look interesting?

We probably could restrict the range in which we search without sacrificing too much. But why not add some long shots to our long shots?

Eric J. Korpela - 2000.01.28 in a.s.s., when asked if S@h is currently crosschecking results:

Yes, but as usual we're far behind real time (we've got lots of results to check before we catch up).

I'd like to make the check real time so we can do the verification before the workunit gets deleted. But that a development I haven't done yet.

Eric J. Korpela - 2000.01.31 in alt.folklore.computers, optimizing the code?

[ >8 ] the code is fast enough, thank you, and running it faster just increases redundancy and server load resulting in DECREASED system efficiency? I especially find it troubling that I need to explain it over and over to engineers that should understand the concept that system efficiency and component efficiency are different things. No matter what we do to the client the data still comes from the telescope at 5 Mbps.

We would like to do more processing on the data, but we got sidetracked by the patch issue. Maybe in another month we'll have an enhanced science client. Again, it won't the the fastest possible on all processors, but it'll be fast enough, and it will do doing the job we tell it to.