October 2000














SETI TIPS, FAQs, et. al.




















(remove NO.SPAM)

Mad props go out to IronBits for hosting the site and all the others who have kept this site going for the past couple of years!.

October 12, 2000

v2 CLI Countdown Begins
Today the version 3.0 winnt command line client was linked up on the download page.� This makes it available for everyone who wants to download it.� But there is also some other significance to the linkage.� The linking also started the clock for the imminent death of the version 2.x command client, both the i386, and the i486 nonintel command line client.� The “death” date is now set for 11/18/2000 for each of these clients.� After Nov. 18, the Berkeley servers will stop accepting results from the old clients.� Make sure you update your clients before then!� For those of you who are wondering about the version 3.0 i486 nonintel CLI…well there will not be one.� There will only be the i386 general winnt CLI.� As of now, there is not death date for the version 2.x WIn/Mac GUI versions.
Don’t miss your chance, go to list of australian online casinos only here good luck awaits you!

Hurry up and start winning with 25 euro no deposit casino at our casino. Limited supply!

Redo Old Work Units with v3???
Well right now the answer is no.� Here is Eric Korpela with the scoop:

There’s no intent to redo data that’s already been done.� Since the project has been extended, and it will be a while before we get an instrument on another telescope, the SETI@home system will likely continue operating at Arecibo.� So we’ll cover the same portions of the sky more times than was originally intended.� So if there are any continuous sources of pulses in the sky, we’ll still get find them without having to reanalyze the data.
Buy best baby toothbrush. Monitor your child’s dental health.
The only scenario in which I think we’d end up reanalyzing would be if there is some interruption in our flow of new data.


But of course, what if the ET signal isn’t a continuous signal, and we may have missed it with the v2 client?� As one person put it so eloquently:

Better to be up to our necks in redundancy than to miss an ET signal…..

Duplicate Results?
During that last server outage on the 10th, I know most of you were having trouble connecting even though the servers were up.� Another thing that happened when trying to connect that many people experienced was the phenomenon of the duplicate results.� There is an explanation of what happened on the 10th and it is different from the random dup. results that occurred a while ago.� here is Lawrence Kirby with an explanation:

What can happen is that the server receives and eventuall processes the result file but the client times out before it receives the confirmation. Therefore the next time you connect it will attempt to upload the same result file. Since the server already has it you get an error back.

ETA:� 3 Months???????????????
If you are a stats pages regular I guess you have noticed the kick in work units the team has in the past week or so.� This is due to a redoubling of WU efforts from some TLC stalwarts…plus an addition of some high producing members to the team.�� During the past week, the team has been producing around 10,000 work units per day!� Leading the way in the past week has been newcomers Support AIDS Research, and Antimoses.� SAR, and AntiM has shot to the top of the production charts with SAR cranking out an astonishing 2019 WU for today, followed by AntiM with 1371.� They are also #1 and #2 in WU average with 873 and 688 WU/day respectively.�

Ok…I know the question that is on all of your minds…WHEN?� Well, with the current production of the team, and if things go the way they have in the past week or so TLC would pass Compaq sometime around the middle of December…maybe earlier.� They way the top 3 are now, once one goes down the others will go down in domino fashion.� Again with current estimates TLC could be #1 in 3 months or sometime in January.�� BUT! Don’t take that for the Gospel though.� I have a feeling that Sun may have some tricks up their sleeves, and they could put up a fight for #1….on the other hand, a fight could be a fun thing :).� –zAmboni


October 10, 2000

Stats R Up
After a delay, the stats are up.� The numbers for all teams were down, but that is probably because of the SETI outage, and then troubles trying to connect to the Berkeley servers.� In addition to today’s stats, I have updated the weekly page.� Go check them out.

Delayed Stats
As many of you know already the SETI servers were down for quite a long time last night/today.� Here is the reason:

October 10, 2000
There was a switch glitch at the Space Sciences Lab last night and we were off the air for a number of hours. This was fixed at 16:30 UT, but things will be slow as the backlog clears for a few more hours.

I am having problems connecting to the server even now at 5:30 ET, and I am sure that many of you out there are experiencing the same problems.� I am going to wait a while before I pull the team stats to give some more time for the members to be able to upload your results…Check back later 🙂


October 9, 2000

Predicting Version 3.0 WU Times
I have put up a little guide on how you can predict your run times with either the GUI or CLI v3 client.� These calculations come from equations developed by Roelof Engelbrecht, and will help you determine the run times on your system based on the angle range of the work unit.� I do have to mention, that these equations do not let you estimate your v3 times based on v2.x results….and are only relevant to one machine.� The run times for version 3.0 can be quite variable, and now you can check to see if your times are in line with the times you may expect.� Check out the guide here.

Team Changes
Many of you may have noticed already, the Virus Entourage has landed again back at Team Lamb Chop.� They are back to say Ni! to TLC, after a short stint back over at KWSN.� Another member to join TLC of note today.� It appears that Roelof himself, the guru of SetiSpy has joined Team Lamb Chop.� He weighs in today in the #49 spot bringing over 5700 WU with him.� Welcome aboard all and enjoy your stay!

Benchmarking News
That venerable denizen Max has weighed in with an update on the benchmarking news today.� Or is that tomorrow?� Since Max is across the pond, today is tomorrow for him, so forgive him for posting the date as the 10th!

Ya Ya Ya…
The stats VBA stuff is still screwed.� As soon as I finish this I am going to see about fixing it.� For some reason the team members whose names start with Ad are showing up as leaving the team and then rejoining.� I have a feeling I know what is up, and it should be fixed soon.� zAmboni


October 8, 2000

OK Its Here!
I know you all have been waiting for baited breath for it, and now your wishes have come true….I will let Hiram let ya know:

Good Morning SETI Fans:

The i386-winnt-cmdline client is ready to go.� It is on the Berkeley ftp servers:

in pub/setiathome-3.0.i386-winnt-cmdline.exe

This client should also function on those CPUs that are currently using the setiathome-2.4.i486-nonintel-winnt-cmdline.exe binary although I haven’t ye verified this is true.� I’m sure I will see messages in the newsgroup here if this isn’t true. There will be no version 3.0 i486-nonintel client since this one client should work in those cases.

I will wait a couple of days before I make this binary visible on the unix.html download page in case there is some horrible problem with this binary.

–Hiram – WB6RSS

Very early reports put the CLI version faster than the v3.0 GUI.� I just installed it, but don’t have any info to post about it yet….I will let y’all know.

There *may* be a bit of a bug in my stats script…..a couple of members showed to leave and join, and that shouldn’t have happened.� Looks like I need to fix it 😛


October 7, 2000

Update on the News and Ramblings
There have been some changes in the news below (from Oct 4), and in the Ramblings that I posted yesterday.� These changes were due from some feedback from both Roelof E., and Lawrence K. and also from more understanding from me about what is going on with the clients 🙂

Something must be in the water today.� From the year plus that I have done keeping the stats for Team Lamb Chop I believe today had the most work units *produced* by Team Lamb Chop ever.� By *produce* I mean work units done by current team members only, and not work units that were gained from member additions, or work units that were lost from leaving team members.� The number of work units produced today was a whopping 10,672 WUs.� Leading the way today to this record was Vomesh who dropped a bomb on the rest of the team (and a warning shot over Compaq’s bow) with a total of 1025 work units for the day.� There are a couple of new additions to the team which helped that total out significantly.� Antimoses joined the team yesterday, and today posted a whopping 921 WUs….He/She/They were followed by Support AIDS Research which put up 619 work units.� Not bad at all.�� Heck even hanser got into the fray by posting 190 WUs today….I know ColinT is off somewhere seething :).�

Keep it up Lamb Choppers!� Compaq is getting closer and closer every day.� At the current pace we shall pass Compaq sometime before the end of the year.� One other thing to sleep on tonight.� This has to do with the version 3.0 client.� Because the new client is more cache friendly, the advantage of the large cache CPUs had with the previous clients is gone.� Those large cache CPUs will experience a relatively larger increase in client times over the previous versions than the so-called “consumer” CPUs.� I have a feeling that Sun, Compaq and SGI rely more on those large cache CPUs, than Team Lamb Chop does…so they may end up suffering a bit more in the client change than we will.� –zAmboni


October 6, 2000

Version 3.0 Ramblings
OK, I have posted a bunch of ramblings about the recently released version 3.0 client.� They most center on equations from Roelof Engelbrecht which relate the number of calculations the version 3.0 client (measured by Lawrence Kirby) will perform based on the angle range of a work unit.� There is also some discussion about the use of the benchmarking work unit for benching the version 3.0 client.� If you are wondering,� we are going to use the same work unit as previously for benchmarking.� There are other ramblings going on and more.� Check it out.

v 3.0 Install Reminder
This is a reminder to everyone who has or is about to install the version 3.0 GUI client.� If you had a previous install of any GUI client, make sure when you install the v 3.0 client that you check the preferences for the new client.� When installing, the new client keeps the settings that you had previously, but the client has an annoying habit of turning on the screensaver when you install the new client even if you had it turned off before.� If you want to run the GUI minimized, make sure you go in and turn the screensaver to “none” in your display properties window.� There are a lot of people on the newsgroups who are wondering why it is taking the S@H so long to process, and they didn’t realize that the install turned on the screensaver.

v 3.0 Humor
There is a new entry over at Clinic Underground, welcoming the arrival of the version 3.0 client.� It is definitely something to check out.� If you haven’t already, make sure to check out the rest of the site also.

Gain Some, Lose Some
A bit ago, TLC gained and influx of refugees from the Knights Who Say Ni!�� Today they are refugees from TLC.� Virus – TLC left to go back to his old haunts, and it appears his entourage that followed him here, left also.� May the cruncher caravan find fertile work unit pastures wherever they may go.� As for the recent new members, don’t let the exodus scare you!� We are a nice bunch………Really!� We are!

The Count Down Begins
For those of you who didn’t believe that the version 3.0 release would be a required release…think again.� There are already some transition dates up for the text version 3.0 clients available right now.� Right now the transition date for each of these clients is 11/11/00.� This means when the client is available for download there will be approx. one month to upgrade before they stop accepting results from the version 2.x clients.� This is taken from the page:

Please note, the following version 2.4 (or 1.*) clients are expected to expire on or soon after the following dates. Please convert to 3.* versions for these clients before these dates. After these expiration dates, these version 2.4 (or 1.*) clients will no longer be able to return results nor obtain work units.

You may say…but what about the version 3.0 GUI versions?� I have a feeling that the grace period for the GUI versions will be a bit longer.� They will have some type of formal announcement sometime in the near future about the release of the new clients, and the countdown will begin from then.

New Jobs…What About the Old Employees?
Since there were some new job postings on the SETI site, some people were wondering if this means they were going to replace some of the team members already there.� I guess this is not necessarily true from this newsgroup posting:

Susan� <> wrote:
> I have not seen Eric post here in a long time now and noted several
>interesting job openings posted up front on the website.� Are all the
>principal players still in place or has there been a shake-up of some sort
>when school started or careers changed?� Maybe these new jobs are in addition
>to the existing team to grease things up even better–my hope?� Thanks.

Hi Susan,

We’re still here.� We’ve just been incredibly busy.� Eric Heien has gone back to classes, so he’s pretty scarse.� Dan is in Rio at a conference this week (poor guy).� Matt’s leaving town for a couple of weeks.� David hasn’t been around too much since joining United Devices.� And I’m busy trying to put together a magazine article, in addition to my other major project getting busy (and being chosen for some NASA funding, yay!).� I’ve also been working on a SERENDIP III paper.� To top it all off, I’ve been put in charge of the science post-processing, so now it’s my fault there hasn’t been a science newsletter in way too long.

I still try to glance at the newsgroups occasionally, but I miss a lot of things.� Hopefully, increasing the size of the team will free up some of my time by removing me from the DBA tasks and most of the programming part of my work.

Eric Korpela

That is all for now…� –zAmboni


October 4, 2000

Its Official
The release of the version 3.0 client became official today when the Berkeley guys linked up the Mac and Windows clients on the download page.� The other unix clients that have been on the ftp servers are also linked up.� One thing to note is that the MacOS X version 3.0 client is actually a public beta….If there is any problems with that one you experience, I am sure the S@H guys would like to know about it.� Another thing to note is that there is yet to be a command line winnt client out.�� I am not sure when this client may become available.� A while ago, there was some confusion on whether their porter for that client was “lost” or not� (word is that the porter is not lost but is alive and well! 🙂….but check back on the unix clients list to see if it becomes available soon.� When you are downloading then new client check out two things that detail the changes in the version 3.0 client.� The first is shown here.� The main things that you all want to know is how will the client run compared to the previous versions of the client.� They expect on average for the new client to run longer than the version 2.x client, but there will be some variability in each individual work unit time (I have seen this already).� There is a good section in the S@H faq that points out why there will be variability in the different work units.� Run times for each work unit will be HEAVILY dependant on the angle_range of the work unit.� The angle_range/slewrate determines exactly what types of searches will be done and when in the work unit.� I have yet to run the gamut of angle_ranges but it appears that very low angle_range work units will process slower, and extremely high angle_range work units will be the quicker ones….mid value angle_ranges will be somewhere in the middle of the run time spectrum.� The second point many of you have been wondering, is how will the S@H guys treat the new results in terms of stats.� Here is what they have to say about it:

Note on execution time and individual/team statistics
The combined effect of FFT optimization, pulse detection, and the extended doppler drift range is that a typical workunit will take about 40% longer to complete with version 3.0 on any given platform. On balance, this gives the project the best science for the CPU cycles used. We trimmed processing where we could to lessen the impact on execution time. This of course affects the stats. It will take longer to add to your results received statistic. While it might be nice to somehow make version 3.0 workunits “worth more” stats wise, we have not added that complexity.

Version 3.0 Cache Friendliness Corrections and Stuff
(Updated 10/7/00) – A lot of what I wrote here before was actually wrong based on my misinterpretation of what the chart in the faq showed….I have cut out a bunch of stuff here, and changed some other stuff.� Most of the stuff that is wrong but I kept to let you see what is wrong is in dark gray text.� Added text is in yellow)

Well, version 3.0 will be more cache friendly.� It seems that in the 2.x clients run times seemed to be dependent on two different things.�� The working set for the previous version 2.0 client seemed to be too large to fit in most of the “consumer” level CPUs on the market.� This is why a larger cache Xeon ruled, and why a PIII Katmai processor out performed a PIII CuMine processor.� The second factor seemed to be whether or not the work unit contained any gaussians.� It appeared with many of those work units that did not contain gaussians, the client decided “there ain’t none here Jim” and the client didn’t even search for gaussians anymore.� This lead to faster times for work units without gaussians.� The version 3.0 client seems to be different in this aspect.� The different searches and when they will occur seems to be dependant on the angle_range of the work unit, as shown in the faq.

Angle_Range vs Search Patterns
At different angle ranges, the client will do different searches.� The chart on the faq shows that pretty well.� Mid value angle_ranges will do all of the searches (gaussian, triplet and pulses), but at the extremes in the angle_range values, gaussian searches will not be done at all in the work unit.� You may think that all of the extreme angle_range value work units will be faster, but that will not be the case I am afraid.� The highest angle_ranges will be the fastest, because gaussian searches will not be done on these clients, plus less searches will be done…and this leads me to… One thing to note about the client, EVERY work unit regardless of the angle_range, goes through the same amount of FFT calculations, and the same spike searches, the only thing different between work units with different angle_ranges are the type and number of searches being done on them.� From the chart in the faq you can probably hypothesize that the mid angle_range work units will take the longest to process because of the extra gaussian searches.� Next fastest work units will be the low angle_range work units.� These work units do not have to go gaussian searches, but there are some added searches on longer FFT lengths…these searches will be significantly slower than similar searches at shorter FFT lengths.� This leaves the large angle_range work units (AR > 1.0) to be the fastest of the work units in terms of processing time.

Angle_Range vs FFT Length
In the previous section I noted how the angle_range determines what type of searches will be done, but it also determines how many searches will be done.�� Again I would like for you to refer to the chart in the faq.� Notice that top line running across going from 128K down to 8?� That is the FFT length.� Check out the work units with angle_ranges >0.1…all of those work units will have searches being done that have FFT lengths of either 16K or less.� Why is this important?� Think L1 and L2 cache of the CPU.� 16K is small enough that it should fit well within the L2 cache of most major CPUs out today (ok except for the cacheless versions of Celerons or other CPUs).�� This is why the work units with angle_ranges > 1.0 should run on the fast end of the spectrum.� These work units have less total searches plus they will not have any gaussian searches being done.

Now if we move to the other end of the spectrum, lets look at work units with angle_ranges < 0.1.� There are a couple of things going on with these work units.� There will be no gaussian searches being done on these work units.� Faster right?� Not necessarily…� These work units will be cache unfriendly because there will be more searching being done at longer FFT lengths and those extra FFT routines will probably take longer to do even though there are no gaussian searches being done.�

What does all this boil down to?� Lets summarize what I think will happen with the version 3.0 client:

1) Client will be less cache dependent.� The Xeon advantage will most likely be gone.� Work Unit times will be more dependent on raw CPU speed than cache sizes.� Also the Athlon/T-Bird will probably report times on par with an equivalent clocked PIII CPU.� I believe the Athlon/T-Bird underperformed with the version 2.0 client because the Athlon/T-bird had only a 64-bit L2 cache bus compared to the 256-bit cache bus of the PIII.� My early guess for the best price/punch for SETI crunching with the version 3.0 client?� AMD Duron.� Only time and benchmarking will tell.�

2) Client speed:

angle_range speed
< 0.1 faster
> 0.1 and < 1.0 average
> 1.0 fastest

So far to back this up (sorta) are some runs that I have done on my computer (PIII 650E @ 925MHz, 256MB RAM) with the version 3.0 client already and here are the results:

angle_range time (hrs)
0.417 5.046
0.417 4.732
0.605 4.656
0.605 4.632
3.505 3.690

I haven’t done a work unit with an extremely small angle_range yet, but I will let ya know how that fares.� Ok well I am working on one right now with an angle_range of 0.065…so that may be several hrs away.

Update: yea I was off playing CounterStrike…so sue me!� :).� Here is some midway data for the current work unit I am processing.� With an angle_range of 0.065, and with 45% of the work unit complete, SetiSpy is estimating the final work unit time to be around 4.5 hours.� This may make it just on par or maybe slightly faster than the mid angle_range work units.� This seems alittle suprising to me at least, I thought they would have been significantly slower than the mid angle_range work units.� I guess the loss of gaussian searching in those work units basically offset the added search time done.�� This is definitely different than some of the early betas where small angle_range work units tended to be at least an hour or two longer than the mid angle_range work units on my machine.� Check out the version 3.0 article for more looks about the run times on the version 3.0 client.

I haven’t talked to RB about the benchmarking and/or the benchmarking work unit yet.� We weren’t sure if the bench work unit we have been using would be representative of the average work unit.� But seeing that the angle_range of that work unit is around 0.4, it should be within the average range.� I have a feeling that the bench work unit will not be on the fast end of the version 3.0 times, but it should be a happy medium.� So what are you waiting for?� Get some benchmarks done!

Update! – I received an email from Roleof (of SetiSpy fame) pointing out an error in the above.� The benchmark work unit is not representative of the “average” work unit.� The angle_range of the work unit is actually 6.718, which would put it again at the fast end of things.� This work unit will not have any gaussian searches done on it.� I think we will need to make a decision on whether or not to keep this same work unit for benching the version 3.0 client.� But I personally am leaning on keeping it (cuz we can directly compare between v 2.0 and v 3.0, and the major factor in determining client speed is the speed of the FFT routine).� We’ll let ya know.

Required Upgrade
The version 3.0 client will be a required upgrade…how will this happen?� Well I will let Matt Lebofsky let ya know about it:

> Is this for real this time? Will v1.x/2.x results simply be rejected or
> is there a way to detect the version number of the client hammering the
> ports and can workunit upload to them be prevented?

Yup. It’s for real this time. When we released 2.x we didn’t bother rejecting 1.x results since we believed that 3.x was around the corner.� Making both 2.x and 3.x mandatory upgrades so close together would have bugged a lot of people, so we just let it slide.

As for the second question, we know the version of the clients sending results back, and we can easily have the server behave in one of three ways:

1) Accept the result and send a new workunit, no questions asked
2) Accept the result, have the client present a warning message saying there’s a new client available for download, and then send a new workunit
3) Do not accept the result and have the client present a warning message saying there’s a new client available for download and the current client won’t work until you get it.

Right now we’re at (1) for all versions. Soon, we’ll make the server behave like (2) for all versions before 3.x. After the “grace period” the server will behave like (3) for all versions before 3.x.

All this logic has been working all along in the client and server, we just haven’t implemented it since the days of 0.x

– Matt – SETI@home

The grace period will be several weeks after the “full-blown” official announcement, whenever that may happen.� They are quietly letting things roll out right now, because they don’t want the download servers to get too overloaded at the moment.� We will have to see what kind of timescale this will be on…and I will let ya know when i find out.�

An Optional Upgrade
While the version 3.0 of the SETI@Home client will be required, there is a new version 3.0 available for download, and the upgrade is not required (although recommended!).� There is a new version of SetiSpy ready for your perusal.� There are alot of improvements in the add-on and it is recommended.�

One thing I want to point out with different monitoring clients and the new version of the S@H client.� With the release of version 3.0, there were alot of people on the newsgroups and the Ars Distributed Forum who were using SetiSpy or SetiWatch to estimate their finishing time for the work units.� At the beginning of the work units people were reporting “hey this is fast!”, but then their excitement waned when they realized that the work unit was going to take longer than they expected.� This can easily be explained from the chart in the faq mentioned earlier.� At the beginning of the work units there are almost no searches being done especially at low frequencies.� This leads the monitoring program think the work unit will finish in a fast time, but when the searches start going, you will see the work unit estimated time to get longer and longer.� A good estimate of finishing time should probably on be taken if the work units is probably around 50% done…or you may be dissapointed!������ –zAmboni


October 3, 2000

Version 3.0 Has Arrived!
Now available for download (ok…unofficially) on the SETI@Home ftp servers (, are the Win98 and Mac GUI version 3.0 clients.� But wait there’s more!� In addition to the normal Win98 and Mac GUI versions there is also a new linux version, and a Mac OSX version available.� The version 3.0 clients that are available for download at this time are the following:


go get ’em if you wanna run ’em


October 2, 2000

New Month…
…and I sure hope that the problems of last month with the site are over.� I am sorry for the problems that we experienced here in the past week.� The problems stemmed from some unexpected server maintenance.� In the future if there are any further server outages here the site will be mirrored courtesy of Knight at� I would like Knight for setting up the mirror, and hosting the pages for the past couple of days while there was downtime.� There are alot of things to cover in this update, so I guess we shall begin!

The weekly stats are up.� They have been up for a bit, but I finally have gotten around to updating the news to tell ya ;).� There has been some happening things going on with the team in the past couple of days…There has been some kick ass numbers being posted by members, an some big moves because of them.� Heavy hitters, start hitting harder:� Vomesh is back and coming on strong, he has cranked up the WU output big time in the past week.� This vaulted him into the #2 producer of the week behind Admins Spend CPUs.� Those work units moved him up three spots to #9 also.� Way to go!� Dropping to #3 this week in production was Knight, but even being knocked down a notch he still moved up 2 spots to #5.� Newcomer Krell Worshippers is making a big splash also, putting them firmly in the #4 spot for work units in the week.� On the movers side this week, Axl came in tops moving up 36 spots.� Huck, house5150 and mkbean all made a strong showing tied for second with each of them moving up 24 spots.� There are alot of people down in the ranks making moves, so those who are in the top 3-400 better watch your backs!

The burst in Vomesh’s output marked a pretty good turn around, once firmly entrenched in the top 1000 users overall in the S@H project, he was in danger of falling out, but with the increase in output over the past couple of weeks he has suddenly spurted back up nearing the top 600.� OoklaTheMok has also turned things around, not quite to the extent that Vomesh has, but he has worked his way up near the top 700 overall.� See what happens when the summer is over and the students get back to school? 🙂

Turning our eyes to the top 50 of TLC, there were some other members making moves up the ranks, rosborn move dup one spot and into the #17 position.� Greens in Oz, spurred by the fantastic show the Australians put on with the Olympics moved up one to the unlucky #13 spot.� Virus-TLC moved up one to #20, Joker broke the 10,000 WU barrier and also moved up one to #23.� Daryle A. Tilroe, JerkyChew, and Beyond all moved up one to #29, 32 and 33 respectively.� Finally Krell Workshippers rocketed up 17 spots into the #39 spot.

Something that many of you may not have known…When the version 2.0 client was released a while ago, it was stated that results from the previous 1.x versions would not be accepted anymore.� This never actually happened.� Even now the SETI guys are still accepting results from the version 1.x clients.� Why?� I will let Eric Heien tell ya:

I believe it was because we thought 3.0 would be just around the corner, so we didn’t want to force people to upgrade only to force them again just a month or two later.

And as for stats on how many people are still running 1.xx clients, it comprises about 10% of results that we get now.� Most of these are probably large computer labs whose admins don’t want to change the software on hundreds of computers unless they really have to.

But don’t expect the same slippage to happen with the version 2.x clients being accepted too long after the version 3.0 clients are released.� Eric also reported that version 2.x results will be rejected “several” weeks after the 2.0 release.

Version 3.0 appears to be here….at least partly.� Some people who I guess monitor the S@H ftp sites religiously have reported that there are some version 3.0 clients which are showing up on the ftp server (� The versions that have been up on the ftp site are:


yup….you saw it, there is a linux version up already.� Some people have already installed the linux version and the early reports state that the linux client may be running significantly faster than the 2.4 linux version.� hrmmmmmmmmmmmmm will have to wait to see if this is true for the majority of people though.� Are these the “real” version 3.0 clients?� Looks like they are.� Usually they put up the new versions on the ftp server as soon as they are available, even if there isn’t a “formal” announcement of the version 3.0 release.

Enjoy the SETI@Home project, and are looking for a job?� You may be in luck!� Several days ago they added a job listing page on the S@H site, posting several job openings within the S@H project…They are:

Database Administrator – Programmer/Analyst IV (Job Number 09-146-10/CP)
Scientific Programmer – Programmer/Analyst III (Job Number 09-141-10/CP)
Webmaster – Programmer/Analyst II (Job Number 09-123-10/CP)
Junior Sysadmin – Programmer/Analyst II (Job Number 09-122-10/CP)
Administrative Assistant II – (Job Number 09-365-30/CA)

There are detailed descriptions on each of the above openings on the job listing page.� If you are interested, check it out.� Looks like they are finally putting some of that recently added fundage to use.
One interesting thing in the description for the Administrative Assistant……

Desired Skills:
HTML, Latex, familiarity with Unix environment, troff

Hrmmm…I always want my secretary to be skillful in latex and experienced in bondage….but that is just me 😉

Ok I skipped a few numbers….but there is a new #10 team overall in the S@H project.� IBM passed CCI Seti Crunshers a couple of days ago.� Congrats to IBM…and good riddance to CCI.��� –zAmboni


-Front Page