Archives

December 2000

Now And Then: A TLC Graphical Retrospective

NT/2K SETI Service/Scheduling

Seti Driver Guide Updated 11/19/00

Official!
Yay!  The S@H guys looks like they are getting their stats all straightened out.  Their team update early this morning finally shows TLC in the #1 position!  If you all were hesitating to spread the news now it is OK to do it :)  Check out the current standings here.

Under the Weather
Folks on the East Coast are bracing for the dumping of snow this weekend...here in Michigan we already have a foot of so of the white stuff on the ground :P  Unfortunately thrown in a touch of the flu for me and things have been moving slowly here.  If my presence has been lacking it is because of that.  Want to talk about fun?  I had to climb on top of the house and shovel off the roof.  I sure hope you had some better things to do with a Saturday!

Google Me This!
Playing around with search engines yesterday and ran across this which is pretty interesting.  load up www.google.com type in "lamb chop" and hit the "I'm Feeling Lucky" button and see what pops up :)  It is nice to see that Team Lamb Chop is on top of more than one list!

Still #2? (No...Not Really)
If we passed Sun Microsystems on the 24th, then why does this page still show Team Lamb Chop in 2nd place?
The answer is nothing more than some screwy stuff going on with the SETI stats servers.   Here is the current standings for both TLC and Sun (12/27 11:25pm ET):

The "Actual" work unit totals are the sum of work units from each individual member from the teams.  The S@H total is what they use for ranking the teams.  Why is there a difference in the two?  Something got messed up either last Thursday or Friday with their stats servers. 

Here is what was happening for the past couple of weeks:

• For people already on a team - work units produced were added into the "S@H" work unit totals

• For people joining (or leaving a team) - work units that were brought over (or taken away) from a team were cached up, and then once a week those WU numbers were added (or subtracted) from the "S@H" team total number.  This cache dump usually happened over the weekend.

Here is what is happening now:

• For people already on a team - work units produced are not added into the "S@H" work unit totals

• For people joining (or leaving a team) - work units that were brought over (or taken away) from a team are added (or subtracted) from the "S@H" team total number immediately.

I have no idea why this is happening now.  The only thing that occurred at the same time as this change was the SETI crew restarted regular daily updates of their top team/user/country/etc... stats pages.  My wild guess on what happened at this time?  They adjusted the server scripting to put these stats pages online, and also decided to make the team changing WU movement immediate, and somewhere in the mix, they introduced a bug in the scripts that is preventing the normal production for a team to get added into their team totals. 

When will it get fixed?  I don't know.  When will TLC be listed as #1 on the S@H pages?  I don't know.  I have relayed this apparent bug to the S@H guys, but with the holidays here, I am not sure when it will get taken a look at.

Still In the Giving Mood
There was some surprising big numbers posted by both hanser and ColinT today.  It turns out that most of these work units were late Xmas gifts from Krell and Antimoses.  You can read more about the gift, and the reasons behind them here.

Caching Program Updates!
There was news on two fronts which include two of the most popular caching programs for the SETI cilents.

First off Mike Ober let everyone know that the SETI Driver site has moved.  You can now find the SETI Driver site at: http://www.wakeassoc.com/SETIDriver/

Second, At the moment the Seti Queue site is down temporarily  Here is the reason for the site being down, and some future plans for the program/site:

Seti@home has updated the client to Rev 3 + which requires program changes to seti queue.  Seti@home has requested some other changes to setiqueue to occur at the same time.   During the holidays I have not had time to address the issues, and now I am on break with my family.  I hope to work on Seti Queue during the early part of Jan 2001.

Happy new year
- Ken

Other Stuff Updated
The weekly pages have been updated tonight.  Check them out if you wish.  Big thing to note is that there are now a total of 30 TLC members who are in the top 1000 S@H users!  Congrats to all of them  3% of the top 100 isn't too bad eh?

Happy Holidays!
While many of you are in anticipation of what gifts may be had tomorrow for Xmas, there has been a bit of giving a day early.  But first off, I would like to wish each and every one of you a good Holiday Season.  While many sit around the tree opening gifts on December 25th, two packages for Team Lamb Chop arrived early.  TLC received gifts from both Antimoses, and Larry Loen today.  The gifts comprised two accounts joining the team.  The two accounts totaled more than 30,000 work units.  With those work units, it pushed the Team Lamb Chop total over 3 Million Work Units, and also propelled TLC past Sun Microsystems into the #1 Team Overall position!  Larry Loen explains his gift in this thread here.  Congrats to all Team Lamb Chop members.  There has been over 3 million gifts that each and every one of you have given to Team Lamb Chop and without them we would never have reached this pinnacle.

Servicing Your SETI Clients!
Punish has submitted an article for setting up SETI as a service in WinNT and/or Win2K.  He also shows a way to schedule the startup and stopping of clients if you want to control things a bit more.  Check the article out if you want some NT/2K SETI Mojo!  Also you may want to check out Panders' guide for more WInNT SETI tweaking.

Antiguru #9
No this is not a newly found Beatles title...  The SETI servers finally have updated the top users page on their site.  As of the update, Antiguru is now the #9 user in the world!  Congrats!  You can check out other TLC members in the top 1000 overall on the top user graph on the weekly page.

v3.03 Bug
This has been reported on the S@H page and may have affected many of you who have switched over to the version 3.03 client already.  I'll let them tell ya what is up:

"OBSOLETE VERSION" BUG: Some windows users are downloading version 3.03 and getting messages saying this version is obsolete. If you do, please exit the client, delete the file: C:\Program Files\SETI@home\version.sah and restart the client. Sorry about the confusion.

NEW BENCHMARKING WORK UNIT!!!
With the advent of the version 3.03 client, and also extensive discussion on the Ars Distributed Forum, it has been decided that the benchmarking work unit will be changed to one that represents the "average" work unit that is distributed on the S@H servers.  For more information check out Max's news here!

Averting Potential Disaster?
Ever since the release of the version 3.03 client, and listening to the comments from the S@H crew on the newsgroups and elsewhere, it has been quite evident to me the main reason for the version 3.03 slowdown was to cut the number of connections to the Berkeley servers.   This has been backed up from some statements from S@H crew in their posts to the newsgroups.  They try to calm the crowd telling them that there is now added science to the client, and that is a why things are slower.  IMO, this late addition to the 3.03 client was an emergency reaction to their server/bandwidth conditions over there at Berkeley.  If this was a long thought problem, they would have added the extra science in the version 3.00 client.

The recent rash of large angle range work units have pushed their bandwidth limits to the brink, and apparently things came to a head today.  There apparently was a rash of connection problems with users today, and it looks like they may be taking steps to weed the problems out.  Earlier today they took all of the cgi pages off-line and user/team stats were not available for a while.  (delayed my stats gathering for a while).  There was a message on the S@H page saying that they were reconfiguring their web server while they had the cgi pages down.  They are also urging people to upgrade to the 3.03 client to help with this bandwidth problem.  Here is what they have up on the main page right now:

SERVER STATUS: Due to reaching our current maximum bandwidth allowed by the University, many connections to the server are being dropped. Please upgrade to version 3.03 if you haven't done so already, which will help reduce the load.

I have no idea what they will do if things get any worse than now....who knows.  I wish they would get some things straightened out...I know that the top users, and the top teams/countries/etc pages haven't been updated in over a week.  Let hope it will get straightened out sooner than later.

Computer Upgrade Update
Ok the PIII 750 wasn't completely stable at 1GHz.  After running over night with SETI going it came out fine, but when I got home from work and started to read newsgroups, I started getting random exception errors.  I had to back down the FSB to 124 for the time being....at least until I can switch back to the BE6r2 over the weekend so I can tweak like a madman! 

As for the dual machine, there is some good news, some bad news, and a lot of question marks (?????)  I want to state this once (many of you already know this anyways :)...The Tyan Tiger 133 is one strange motherboard. 

1) The good news: I fooled the board into thinking the 650s I have installed are 133 MHz CPUs.  I did the old "A14" trick.  Borrowing the gf's nail polish I covered the A14 pin on the CPUs, and now the board now is running at 133 FSB, and the computer is cranking now at 866 MHz. 

2) The bad news: the Tiger 133 seems to be very finicky with the video card is uses.  I have checked on various boards and newsgroups and have seen frustrated users trying to get their video cards to run on the machine.  I currently have a Matrox G200 AGP installed and the computer is fine running SETI for hours on end...but if I go in and start checking around directories or other things, I end up getting a screen freeze/lock, and have to reboot.  It appears the problem is the AGP port/drivers for the board, and I have seen alot of people with similar problems.  There are only a few "approved" video cards for use on the board, and of course there is no mention of any Matrox cards there.  I have tried changing the AGP driving values like some people suggested, but the values I tried, only seem to make it worse. 

3) The Very Strange:  I had mentioned previously that the Tiger doesn't have the option to change the FSB within the BIOS, and that one has to rely on the autodetect of the CPU to set the FSB.  Trying to use SoftFSB didn't work on the machine, and I did try to use CPUFSB also without avail.  After I wrote the news yesterday, on a whim I was playing round with CPUFSB again last night...and I got it to work in changing the FSB of the box.  (note: this was before I did the "A14' trick).  I was able to get CPUFSB to change the FSB to 124 MHz, and the FSB change was confirmed using WCPUID.  I tried going higher, but at 133 FSB, it wanted to change the PCI divider to 1/4, and that doesn't go over too well while booted into the OS.   I fired up SETI on each CPU and went to bed.  After work tonight, I checked the log of the results and there was something strange going on.  The work units that were processed at 804 MHz (124 FSB) took about 1-1.5 hours longer to process than the work units at 650 MHz (100 FSB).  This is where the question marks started ???

I decided to benchmark the machine to see if there was something funny going on somewhere.  I first benched at 124 FSB, decided to reboot....and guess what?  Upon reboot the FSB stayed at 124 MHz, I didn't have CPUFSB running on startup, this showed 124 FSB in BIOS!  Why didn't it reset back to 100 FSB???  Oh well....somehow I got the thing to boot at 100 FSB and did some more benches.  (fire up the twilight zone theme)  Result:  The Sandra CPU and Memory benchmarks at 650 MHz (100 FSB) and at 804 MHz (124 FSB) were the same!!! Now could *someone* tell me what is going on here?  I still cannot rationalize why the BIOS, Sandra, CPUID, and even SetiSpy showed the CPU speed to be 804 MHz, with a FSB of 124, but the machine benchmarked acting like a 650Mhz machine....and it spit out SETI WU times slower than running at 650 MHz

Now that I did the "A14" trick, I also benched the machine at 866 MHz (133 FSB) and the CPU benchmarks seemed to be where they were supposed to, in line with the increase in the CPU clock.  The memory benchmarks were also higher, in line with the increase in FSB.

Enuff of the strangeness...

One thing to note with the benchmarks was that the Memory Benchmarks seemed quite low.  After a bit of poking around with WPCREDIT, and taking a look at the registers, it seems that 4-way interleave is not set, heck 2-way interleave isn't even set.  There was no interleave set at the time.  Looks like this board will need ALOT of tweaking to get it to run at its full potential.

Also did I mention that the hardware monitoring is screwed also?  At least CPU #1 seems to be showing correctly....CPU temp being 109 F, running at 1.65V, but it is showing CPU 2 running at 204.8 F with a core voltage of 3.28V....hrmmmm.

About Last Night...
Jim Belushi, Rob Lowe and Demi Moore...pretty good movie.  But that ain't what I'm talkin' bout.  Yes, I do sometimes get out of the house and have some fun!  (Say Mantra: "Stats Do Not Rule My LIfe").  Last night I drove down to big bad Detroit and caught some puck action!  (WOO!)  It was a pretty good game, Detroit tied the game with less than a minute left in regulation, and then scored the game winner in overtime!  BTW..I do think that Karen Neuman is a slut!  OK lets get back to something SETI related here :)

I know that many of you are tweakers and hardware enthusiasts, Even though I may be of limited fundage, I happen to spend way too much money on computer hardware.  I do love to tweak and prod machines to get the most out of them...and if they aren't giving me enough...UPGRADE!  :). The problem with this is that things tend to get out of control.  It is a vicious cycle, I tell you!  I tend to find any reason to buy something, just to justify a purchase, even though I don't need it.  I know many of you are the same!  I had been putzing around with a couple of systems, all of them running the v3.00 CLI.  They consisted of the following:

1. PIII 650E @ 923MHz, Abit BE6r2, Win98SE (my main machine for gaming, writing this, etc.)

2. PIII 600E @ 744Mhz, Abit BX6r2, Win98SE  (girlfriend's computer, prolly could clock higher, but she doesn't want more fans cuz it is in the bedroom and would be too noisy)

3. Celery 300a @ 450MHz, Abit BX6r1, WIn2K Pro (Used to be my main computer once upon a time, but now is a machine to play around with Win2K on)

4. p166 @ 120Mhz, MoBo???, Win98SE (My first CPU in my computer bought about 5 yrs ago.  Why underclocked?  Took the CPU out, and put in an old Compaq Deskpro 590, took out the p90, and put in the 166...but the motherboard would only gou up to 120Mhz!  I use this machine for my SetiQ server).

Soooooooo..........why would I need to upgrade?  Here is my warped logic and reasoning for spending money:

I got the gf to buy me a Voodoo5 5500 as an early xmas present.  I installed that in machine #1, and it would lock up at 923MHz.  Why?  The BE6r2 only had a 1/1 and 2/3 divider for the AGP bus.  The V5 just didn't like running 2/3 @ 142MHz FSB.  So.......I went out and bought an Asus P3V4X.  Well that gives me a 1/2 AGP bus divider...BUT as I soon found out I had a later revision board, and instead of the 32 FSB choices the early revisions had, this one only had 16.  Bah.  I was stuck with using either 133MHz or 140MHz FSB.  The puppy didn't like 150Mhz.  So I ended up having to clock back the machine to 910Mhz.  WE CANT HAVE THAT CAN WE?  So I got thinking...(amazing isn't it?). 

How about this...Buy myself an xmas present, a PIII 750.  I can replace the 650 with the 750, then I can go to lower FSB on the P3V4X (or the BE6r2), the vid card will like the lower FSB, PLUS If i can get it to work at 133Mhz, I would break the magical 1GHz Barrier!!!!!!!!  Then I replace the Celery with the PIII 650, and eventually one day get a dual board and another 650 for the dual board.  The 750 was on order, and lo and behold, there was a computer show this weekend in Detroit.  So guess what I bought?  Yup another PIII 650E, and a Tyan Tiger 133 board.  The 750 arrived early yesterday morning, and I installed it in box #1, of course what is the first thing I try?  Yup....it booted at 1GHz, but it locked quite easily.  I didn't have time to tweak the thing so I clocked it back to 124FSB (930 Mhz) and let it burn in all day.  Installed the twin 650s in the dual board and they are working fine right now :).   About an hour ago, I thought the burn was good enough...bumped the voltage up to 1.85, and set for 133Mhz.   It has been running stable right now for a couple of hous!  WOO!  Check out the current results in the pics below:

Am I satisfied with what I have right now?  HELL NO!  I am probably going put back the BE6r2 board instead of the P3V4X, mainly because of the FSB options of the BE6.  I want to see how far I can go with the 750, and the 1Mhz FSB increments will help.  What about the V5?  I know it is fine in the range between 133Mhz and 140MHz, so there shouldn't be a problem on the BE6.  About the Dual board?  Unfortunately, Tyan decided that they weren't going to put in any FSB selections in the BIOS of the board.  It auto-detects the CPU and sets the FSB at either 100Mhz or 133Mhz.  I tried using SoftFSB from H-Oda, but that didn't work with the clock generator on the board (even though it did have a setting for it.  I also tried CPUFSB on the board, and I DID get it to work.  BUT...only with one CPU installed!  I was able to change the FSB to 124MHz, but it didn't work (with 1 CPU) at 133.  That was probably because it changes the PCI divider to 1/4 at a 133FSB and the system didn't like that (FSB changes were confirmed through CPUID.  I tried several times changing the FSB with two CPUs installed, and it just didn't work.  CPUFSB reported it as changed, but neither CPUID or SetiSpy showed that the FSB change worked.  I do have one other option though.  I caught a reference to a page where someone modified the board with some dip switches, to fool the board into changing the FSB to 133.  Also Inserted switches to control the CPU voltages.  I may have to get out some PCB, and a soldering iron and try that out :).  What will I do with the spare celery 300a?  I'm probably going to take that and build another box with spare parts and make a linux box out of it.  More things to play around with!  Fun!

The Dual and the 1GHz machines aren't tweaked out yet.  They are sort of set for stability right now just to see how things go.  What about WU results?  I don't have anything from the 1GHz machine yet...but the duallies each did a 0.417 angle_range work unit in about 6.5 hrs each.  I am sure I can knock that down a bit easily with a little tweaking....and that will be something to do tomorrow I guess :).

Weekly Stuff Is Up...
Ok it is not complete yet.  Unfortunately, they have not updated the Top Users and the Top Teams pages in over a week.  Come on Berkeley guys, the stats servers seem to be rocking right now.  Why can't you get some regular updates on some pretty important pages???  Check out the weekly page at least for the updated team graphs, and some pretty incredible milestones that were passed in the last week.  Congrats to all the milestone breakers for the week!

Version 3.03 CLI Times
I will let Lawrence Kirby show you how it performs (from a post of his on the alt.sci.seti newsgroup:

I've started my usual set of measurements and here is what I have so far for 3.03 (also given are the nearest equivalent results I have for 3.0). This is on Win2000 which may be significant.

Machine     Client    angle_range       flops              cpu_time

PIII/800      3.0CLI        0.417          2.886E12           16532
PIII/800      3.0CLI        0.455          2.939E12           16869
PIII/800      3.0CLI        0.798          2.829E12           16388
PIII/800      3.0CLI       10.867         2.170E12           12546

PIII/800      3.03CLI      0.417          4.050E12            25480
PIII/800      3.03CLI      0.468          3.990E12            25164
PIII/800      3.03CLI      0.801          3.917E12            25077
PIII/800      3.03CLI     11.358         3.328E12            21417

The first 3 for each client are mid angle_range and 3.03 takes about 50% longer than 3.0. The last is a high angle_range and 3.03 takes about 70% longer than 3.0.

Forum Spotlights
Even though I don't highlight many posts from the Ars Distributed Forum, It is a great source for information and is a top spot to get any questions you need answered about SETI, Folding@Home and RC5.  Hop on over there to check some of the action out.  There are some threads if interest right now especially with the release of the version 3.03 client.

First off Mike Ober has let everyone know that SetiDriver works just fine and dandy with the new v3.03 client.  He tested a worse case scenario out where he switched clients with 4 results cached, and while in the middle of processing a WU with an old client.  The upgrade went all as planned, with all the old results sent fine, and even the partially done WU was finished without restarting.  How so?  Well SetiDriver uses the *client* to do all the communication with the Berkeley servers.  When you upgrade the client with SD, is saves the old client, checks to see which result needs which client, and then uploads/downloads appropriately.  As for the partial work unit done, SD sees that it was started using the old client, and continues to use the old client until finished.  When SD sees that the old client is no longer needed, it proceeds using the new client.  Cool eh?  Pretty much a seamless upgrade.  If you need more info in upgrading with SD, or have any questions, check out this thread.

As a contrast to SetiDriver, SetiQueue is not seamless.  SetiQ is going to need a version update to allow use with the version 3.03 client.  Unfortunately, all attempts by people to contact the SetiQ writer about a possible upgrade has been done without success.  There has also been a call to arms (call to coding?) by ColinT, for improvements on SetiQ, mainly for a Graphical type of interface for ease of use, and the functionality that is contained in SetiQ.  Currently there are efforts going on by several people in this effort.  If you want to eavesdrop in the conversations, then check out this thread.

Looking for a cheap SETI crunching solution?  Then this thread may be for you!  It happens to be a thread that just wont die :)

Finally, the last for this installment is Chazz.  Chazz asks "Do any of you realize how fast Team Lambchop has evolved?"  It looks to be an interesting read.  The team has evolved several fold.  Yes there are several heavy hitters on the team, but the strength in Team Lamb Chop is the core users who are serious about the team and the project.  I have something to say about the evolution, but I am going to save it for the forum thread :)

IRC Pimpage
I haven't mentioned this in a while, but I think it is needed, since it is *one* of the reasons for the TLC evolution.  It happens to be the IRC server that Ancala has been running for a while.  You can access it by joining the server irc.kulish.com, and joining channel #seti.  During the day there are usually people hanging around just chatting it up.  It tends to be an international crowd that hangs out.  You can find the list of regulars there, ColinT, Ancala, hanser, LordZygen, rulesnut, JTrinkle, Tyranny, SirRobin, vwfr3ak, and a cast of thousands!.  Not to be left out are those who are usually up past their bed time on the channel like Geordie, Krell and Antimoses (all from across the pond).  There are there to just hang out and chat, and will be glad to answer any questions you have :)

How pHat Is Your Pipe?
In light of the recent connection problems to the Berkeley servers, one person asked what kind of connection they have over there at the S@H offices:

>Just one question:  How fast Internet connection do you have over there?

We get 100 Mbps, but the University is currently limiting us 30 Mbps for financial reasons.  Our 30 Mbps costs the University $18k/mo.  The University is likely to require the SETI@home start paying for its usage at some point.

Because of this, we've added more science to version 3.03, which should reduce our bandwidth somewhat.  We're also actively seeking donations of bandwidth.  If anyone out there know of a company that might be willing to donate bandwidth, we'd be very happy to hear about it.  We're working on distributing servers to other Universities and companies, but bandwidth costs are high enough that people are thinking twice before jumping on the bandwagon.  The alternatives are to come up with the funding or to convince the University that SETI@home is good for both California and the University itself.

It is easy to criticize the Berkeley Gang on their decision to lengthen the WU times in the version 3.03 client, but you do have to look at the entire situation.  Right now UC-Berkeley is footing their bandwidth bill.  That is a good 216K bucks a year saved for the S@H project.  If they exceed or ask for a bump in their bandwidth allotment it is most likely that UC-Berkeley will make S@H pay for their bandwidth bill.  There are other things the slower client will buy.  One of the reasons why they shut down the last 10 work unit pages were because they put a huge strain on the data servers.  Another reason was the increased bandwidth to their pages that this resulted in.  With more and more people joining in the SETI effort, every bit of bandwidth saved, the better for them. 

There is also one last thing I'm going to hit on here about bandwidth.  Many people on the newsgroups and elsewhere have been complaining about the lack of "results" and/or "science finds" on the S@H site.  There have been hints that in the near future, they will be improving and expanding the site, adding these types of pages.  To be able to provide these services, they will need added bandwidth.  Hopefully the savings in bandwidth will let these other site features be implemented, and soon.

More on Version 3.03
There are other clients slowly showing up on the SETI FTP servers (ftp://alien.ssl.berkeley.edu/pub/), Included in the list is the command line client for v 3.03, which can be downloaded here.  There also are a couple of solaris, linux and other odd clients for your download pleasure!

So what about times?  I haven't heard of any definitive times for the new client, but both the GUI and CLI are significantly slower than the version 3.00 client.  The new client may be 30-50% slower, or even more.  Hrmmmm...looks like the benchmarking page will need to be revised! 

A note for at least SetiQ users, version 3.03 will not work (at this moment) with SetiQ.  The reason why is due to the change in the server address that is used to connect to the Berkeley servers.  A revision will be needed to SetiQ to be able to upload and download with SetiQ.  I am not sure if the same is true for SetiDriver.  There may be a solution for those who want caching for the new clients.  There is a relatively new caching program called SetiGate.  Not too many ppl have tried it yet to see if it is any good :)....you can catch a flavor for what it may or may not do in this thread.

Connection Problems Identified.
Welp it seems alot of people have noticed the proliferation in very high angle range work units in the past week.  Many of you applauded the arrival of them since they process extremely fast, and hence more work units per day!  But unfortunately for the Berkeley servers, these work unit apparently have been causing the problems with connections to their servers.  This is what was reported on the tech news page:

December 12, 2000
We've actually figured out what the problem is, and it took a while. The problem was actually related to something else that was reported on the newsgroups: Workunits with an angle range of 11.

The problem was that for some reason the telescope was slewing at high rate for several days. Of the last 1.6M workunits we generated, 780,000 were at an angle range of 11 to 12. These workunits complete in half the time that a normal work unit does. That means that our attempted connection rate went up by about 30%. Once these work units disappear from the disk the servers should get back to normal.

Right now there are 285562 of these high angle range workunits on disk (out of 633196 total). I'd expect they will be gone by some time tomorrow.

Some of you will be disappointed to hear that the very high angle range WUs will soon come to an end....and the following news won't improve your mood that much more either...

Version 3.03 Available for Download
The bugs seem to be squashed, and now the new version of the S@H GUI is available for download now.  There are some changes in the 3.03 version, and some that I really didn't expect.  There was one statement from the news from Dec 11, that confused me: "The release of version 3.03 should help alleviate the problem."  I scratched my head trying to figure out what they meant by that comment, but from reading the changes in the new client it does become clear what was meant.  Here is what was included in the changes:

Windows

• Fixed a bug whereby the FFT graph would often not be displayed.

All platforms

• Added additional science coverage. We now do a thorough search out to a chirp rate of +- 20 Hz/second. The cost of the additional coverage is that clients will take longer to process a workunit.

  Why are we doing this? We have always aimed to balance scientific return with the resources available to the project, the main one being of course our very large and active community of participants. The growth of this community is what enabled us to increase science coverage in version 3.0. Here we were also trying to balance scientific return with the speediness of workunit processing and so we did our most thorough searching out to only +- 10 Hz/second. We sacrificed some science to gain speediness in the client.

  Another important resource to the project is our pipe to the Internet. UC Berkeley has been quite generous in allowing us to use the campus ISP, given that SETI@home accounts for 30% of all UC Berkeley Internet traffic! This is an expensive resource ($18,000/month). It has gotten to the point where campus has had to limit our bandwidth usage. We are limited to 30Mbits/s outbound (most of our traffic is outbound). This in turn is resulting in connections getting dropped and generally sluggish server response. We need to back off our bandwidth consumption.

  Fortunately, we can do this not by an artificial slowdown but by gaining more science. So, yes, you will see the client slow down, but the server response should pick up. More importantly, you will be doing more science.
  

• Fixed a small bug whereby triplet times were recorded incorrectly in the state file. The times sent back in the result file were correct.
  
• Added a mechanism by which the server can tell the client that it is obsolete and the client will remember that. This will prevent obsolete clients from continually contacting the server.
  
• Changed the alias of the server host. Both the old and new names will be in effect for a while. At some point, we will turn off the old name. The reason is that when we set our server to reject requests from older versions of the client, some of our really old clients (1.x) and some (otherwise great!) third party buffering programs don't have the correct logic to recognize what is happening, and they will keep retrying. By continually contacting our server, they will waste precious bandwidth. Once we turn off the old server name, they will no longer be able to reach the server.

Sorry if it hurts your eyes, but I highlighted the part that many of you wont like in yellow.  Version 3.03 will probably take longer to process than the version 3.00 client.  Why is it slower?  The client is performing more work than before.  This isn't a major "addition of science" like the addition of triplet and pulse searches they added in version 3.00, but like performing more searches within a work unit.  Why did they do that?  Well with the proliferation of large angle range WUs in the past couple of days, it uncovered and magnified the limitations they have with their servers at Berkeley.  They push the limits to their servers and bandwidth available to them running the S@H project.  Normally, they have some room to spare, but it not that much room.  Their two main options to give their servers more room are: 1) Increase server capacity/bandwidth with money they don't have, or 2) Lengthen the processing of a work unit so clients will not connect as quickly, and therefore reduce the load.  They chose #2. 

The other major change in the client is the changing of the server host.  Version 3.03 will be a forced upgrade (eventually).  Right now all of the clients resolve to the same address.  When the "death" date for old clients comes along, they will shut down the address for the old clients, and switch the address for the version 3.03 clients to a new address.  This will prevent all previous clients from connecting the servers to upload/download data.  This would effectively force the user to switch clients, or not be able to crunch any more!

Officially it only looks like the Windows, Mac, and Solaris 3.03 clients are ready for download, there are a couple of minor 3.03 clients on the ftp servers.  I am not sure when other 3.03 text clients will be available.  The other question I know you want to know, is when will this forced upgrade actually be forced?  Dunno.  It probably won't happen until another month or two down the line.  But I will let ya know when I hear it will happen!

Finally...
On the alt.sci.seti newsgroup Matt Lebofsky posted about the release of the version 3.03 client, and made known that there will soon be a S@H mass mailing.  Not toomuch exciting in the mass mailing that will be going out.  A project status (nothing you didn't already know), notice of the version 3 release (been there done that), announcement of the new partnerships with OneCosmos.net and Planetary Society (old news!), and some new S@H stuff for sale.

Berkeley Connection Problems?
I am not sure what is going on, but I am having problems (others also) connecting to the Berkeley servers right now to upload work units.  The server status page says things are up and running fine.  I can ping the data server fine.  But it has been over 2 hours and I have only uploaded 7 of the 12 work units that I crunched.  There have been reports from people over in Europe that have had problems connecting to the servers for the past couple of days, some are running seriously low on cached work units.  What's going on?  I have no idea.  This just in from the SETI offices on the tech news page:

December 11, 2000
Lots of people have been reporting connection problems. We've looked at our server performance and don't see any apparent problems. We are running fairly close to our campus bandwidth limit, which could be causing some problems. The release of version 3.03 should help alleviate the problem.

Well even they don't know what is going on...

Speaking of Version 3.03...
I received this email a bit earlier today.  Looks like the new GUI version (version 3.03) is now available for download.  This appears to be a non beta version and is a release verison!

Some final tweaking was done to some flagging which will hopefully prevent old clients from contacting our server when they are obsolete. Everything else is still the same from the 3.02 build.
Thank you everybody for the bug reports and feedback! I am sorry if I never contacted you personally - all comments were helpful. Most bugs reported ended up being user configuration problems/conflicts rather than SETI@home bugs.
We will force an upgrade to 3.03, so either get them now or get them when they are official (i.e. linked to on the home page).
A (hopefully thorough) page describing the deltas between 3.0 and 3.03 will be up on the site when the download is official.

(Links removed)

Ooops I guess it is in a sort of "limbo release" version....just saw this post on alt.sci.seti from Eric Korpela:

Assuming that all goes well in the next 24 hours it will be a release version.
It will be made available for all the platforms we support..

Eric

I'm not sure if there will be a simultaneous release of the CLI/text/unix versions of the 3.03 client at the same time, but I guess we will have to wait and see in the next day or so.

New Version of Seti Spy In the Works?
Ran across this on the newsgroup also (from Roelof):

Regarding the next SETI Spy update: I have a number of fixes and enhancements on my short-term to-do list and hope to get a most of them done in time for an update this weekend. The SETI Spy website hits have dwindled to about 4,500 per week (the highest was 16,300 per week), so I guess it is time for another update!

Probably the biggest new feature will be the capability to calibrate the SETI@home progress percentage to make it more accurate. This will improve the MegaFLOPs and CpF estimates as well as the Estimated Total Time. The calibration factors will be user definable, and are expected to depend on the SETI@home client type, the CPU type, and the angle range of the WU. I hope that the SETI Spy community will work together in calculating and sharing calibration factors.

Well, that's all for now.

Roelof
--
If you care about your SETI@home performance,
get SETI Spy at http://pages.tca.net/roelof/setispy/

Final Words
The weekly stats up up.  Check them out if you wanna :).  Current date for regaining the #1 spot?  December 28-29.  One thing to note also....to reach #1 it is going to take at least 3,000,000 WUs!  Pretty amazing eh?  Also on the amazing thought...

Results received	249001478
Total CPU time	494319.78 years

The SETI@Home project is rapidly approaching 250 million work units processed, and a total of 500,000 years of CPU time donated to the project.  Some pretty impressive numbers!

The Nameless Evil Owl
I am sure some of you looked at the stats for today and raised an eyebrow.  Yea things look kind of messed up with some of the stats, and it is due to one of my stats coding "features".  Evil Owl who was/is at the #11 spot changed his name today...er not really changed it, more like got rid of it!  Evil Owl now has no name, and that places him in a category with 159 other nameless ones.  Unfortunately there isn't a really good way to tell who is who when you have 159 ppl with the same name!  So the stats get a bit screwed up when a person with alot of work units changes their name to a duplicate name on the team.

The Bar Is Now Set.
The goal of reaching the #1 team overall has been reached for TLC twice.  But through careful manipulation of accounts, and where they resided, TLC was knocked out of the #1 spot each time.  Today was probably the day that TLC would have reached #1 for a third time, but that didn't happen.  Changing form, and crossing up what many people expected, guru left the rnoggin team yesterday and joined up with the Sun Microsystems team.  This shot Sun a couple hundred thousand work units ahead of TLC, and puts off the retaking of #1 for a couple more weeks.  The bar for #1 seems to be set now, since guru is out of accounts to switch around now, they all are on Sun (unless there is some unknown account hiding somewhere).  It looks to be a straight up race now between Sun and TLC, and early estimates for TLC regaining #1?  Dec. 24/25.

Back to #2
Over the weekend TLC passed up SGI again for the #2 overall team.  This time it looks to stick, unless some member of the to 10 decides to move on.  Lets hope that wont happen :).  How does it look for retaking the #1 position?  Well there are really two approximate dates to keep in mind Right now TLC is about 90,000 work units behind Sun Microsystems in the standings.  At the team's current production, TLC is poised to pass Sun sometime around 12/8, sometime later this week.  But, as before, that may not last long though.  guru is out there waiting in the wings, most likely when we pass Sun or sometime thereafter, look for him to switch his guru account over to the Sun Team.  That account right now has about 250,000 WUs with it and would mean about another 15-20 days to make up.  Hrmmmm, TLC passing Sun (for the last time?) on Dec 25th would make a nice Xmas gift....or even if it would be delayed to Dec 28th wouldn't be too bad either.  It would be a nice birthday gift for me :) 

Supercomputing Power! (?)
There was an interesting post on the Distributed Forum yesterday, it was from Krell who was passing word along from his London admin friends who are responsible for www.care.org:

"Hey there.. Some fun for you when you get back: we've tapped a supercomputer for the weekend, and you'll see the results on Monday or Tuesday.. Prepare :)"

Now we will have to see how that turns out...keep note of the www.care.org numbers in the next couple of days to find out!

Congratulations!
Over the weekend Team Lamb Chop crowned a new #1.  Antiguru (the combined efforts of Antimoses and Krell), moved up into the #1 position.  Pretty impressive numbers from our overseas friends.  Speaking of Krell, there was word of Krell's impeding absence for a week or so while he/she goes on vacation for a while.  Maybe they'll meet up with S.A.R in Greece!  We'll be waiting for your return :).

#1 or Not?
Some people have noticed on the Berkeley site that it is listing TLC as the #1 team overall right now.  Why is TLC standing at the #1 position on the Berkeley site right now, but not in actual work units of the team?  Well I have to bring up something that Eric Korpela said a couple of days ago:

At some point, in an attempt to speed up the stats processing we started caching group database entries in memory for large periods of time between database updates.  It worked, we are able to keep up with the stats fairly well.  Unfortunately this introduced a bug when people joined groups.  The database entry would be updated, but this update would be lost the next time a cached entry was written to the database. 

I've fixed the problem, additions to the group will get their preexisting workunit totals updated in the database once a week.

Well what does this mean?  From doing the stats I've noticed that the Berkeley servers would get screwed up in their totals when a person joins or leaves the team with work units.  What *should* happen is for the Berkeley servers to subtract those work units from the team's total if a person leaves, or add them to the total when a person joins.  But what happened is that those modifications would get cached in memory but it got lost.  That is why over a period of time the the Berkeley numbers tend to be a bit different than the acutal WU totals from the team.  I have a graph showing how much this variation can be (click on the pic for a bigger version):

But the problem they had is supposed to be fixed and the moved work units should get updated once a week.  They updated everything several days ago, BUT!  when guru left the team, the Berkeley servers did not subtract his work units from the team totals....so right now the TLC totals on the Berkeley servers are about 200,000 + Work Units more than they should be.  Because the numbers are higher than they should be, the TLC total on the Berkeley servers are higher than the Sun numbers, and therefore they show us to be at #1  (follow me? or have I lost ya? :).  If things go as Berkeley says they should, they will dump their cache sometime in a week and the team numbers would be what they should.  We'll have to see.

CPU Upgrades
Unfortunately, it wasn't me that had a CPU upgrade, but the Berkeley servers did.  The servers were down for a while yesterday while they switched a couple of CPUs from one server to another one.  The outage was a bit longer than they expected due to some undocumented changes they needed to make to the servers, that they didn't know about :P.  Here is what they had to say about the upgrade on the newsgroups:

We moved two CPUs from the science database server (which isn't the same as the data server that serves work units) over to the user database server because the former was doing fine and the latter was struggling. The effects of this hardware move remains to be seen - we're still recovering from the extended outage.

Why was it extended? Because according the E450 manual the CPUs are plug-n-play. I just moved some CPUs around in Ultra2s and that was indeed the case. However! Without any mention in the documentation, you not only need to move CPUs in E450s, but you need to transplant analogous voltage regulators as well. So we thought we lost a couple CPUs in the process until a rep at Sun shed some light on the situation.

- Matt - SETI@home

Just for funlike, I have been working on some new stats for the top 200 teams, and the code that I have times how long it takes to download the data for the top 200 teams.  I had times for the download before the upgrade, and did a similar timing last night (24 hrs later than the first) after the upgrade.  The verdict?  Before Upgrade - 7159 seconds (119 min).  After Upgrade - 4322 seconds (72 min).  The CPU upgrade appears to have improved the download about 40%!  But again that is only one set of benchmarks and....but it is definitely an improvement :)

FYI
Just saw this on the newsgroup.  They have posted a S@H newsletter #5 today.  There really isnt that much interesting sciencewise, but it does go over the hows and whys of their telescope positioning.  Check it out!

Team Stuff
Wanted to drop some names on ya tonight.  First off is a new TLC member that may be familiar with many of you.  Today Mike Ober joined Team Lamb Chop in the #51 position.  If that name isn't familiar to you, Mike is the author of the pretty good caching program Seti Driver!  Welcome aboard Mike!  If you haven't checked it out already, take a look at Poof's Seti Driver Guide.

On the talk of guides, I was thinking last night (yea doesn't happen that often), and I will probably be updating the way outdated review of both SetiSpy and SetiWatch.  Look for it sometime soon :)

The combined Antimoses/Krell effort, codenamed Antiguru, moved into the team #2 spot today.  The combined effort cranked out 10,000 WUs in the past 24 hrs.....Kick A**!

A noteworthy milestone occured yesterday.  Longtime TLC member Vomesh passed the 50,000 WU mark!  Congrats!

-Front Page