|
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.
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.
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.
Eric
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
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 :)
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
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:
ftp://alien.ssl.berkeley.edu
ftp://setidata.ssl.berkeley.edu
ftp://serendip.ssl.berkeley.edu
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.
BTW...
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 :P
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 :)
Woah
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
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 <Susan4ET@DAMearthSPAMlink.net>
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
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.
Benchmarking?
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
Version 3.0 Has Arrived!
Now available for download (ok...unofficially) on the SETI@Home ftp
servers (ftp://setidata.ssl.berkeley.edu/pub/,
ftp://serendip.ssl.berkeley.edu/pub/)
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:
setiathome-3.0.i386-sco-sysv5.unixware.tar
setiathome-3.0.sparc-sun-solaris2.6.tar
setiathome-3.0.i386-pc-linux-gnu-gnulibc2.1.tar
setiathome-3.0.i686-pc-linux-gnu-gnulibc2.1.tar
setiathome_mac_3_0.hqx
setiathome_macOSXPB_3_0.hqx
setiathome_win_3_0.exe
go get 'em if you wanna run 'em
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 http://24.31.11.184/.
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!
1...
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.
2...
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.
3.0?!?!?!
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 (ftp://serendip.ssl.berkeley.edu/pub/).
The versions that have been up on the ftp site are:
setiathome-3.0.i386-sco-sysv5.unixware.tar
setiathome-3.0.sparc-sun-solaris2.6.tar
setiathome-3.0.i686-pc-linux-gnu-gnulibc2.1.tar
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.
4...
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 ;)
...10
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 |
